object-oriented approach both the problem and its solution is represented as a collection of objects...
TRANSCRIPT
Object-Oriented ApproachObject-Oriented Approach
Both the problem and its solution is represented as a collection of objects that unify data and behavior descriptive of entities involved.
Objects are subject to classification based on shared traits or similar characteristics. Hence each object can be an instance of a class.
Object Hierarchy, Base ClassesObject Hierarchy, Base Classes
Classes are often organized in a hierarchy with one or more base classes serving as roots of hierarchal relations.
Subclasses are derived from base classes (aka superclasses).
A derived class inherits all the features of the base class, but can introduce its own specifics or deviations from the original behavior.
Abstract Classes, PolymorphismAbstract Classes, Polymorphism
Abstract class: a class that cannot be instantiated directly, it can only serve as a basis for deriving subclasses.
Interface: “distilled” abstract class (no implementation details whatsoever).
Behavior: action or transformation an object can perform or be subjected to (can be expressed as a collection of methods and events).
Polymorphism reflects the fact that subclasses differ among themselves and from the base class.
Benefit of ObjectsBenefit of Objects
Abstraction: makes difficult concepts look simple
Encapsulation: hides unnecessary detail
Polymorphism: allows for specialization of general behavior
Do objects really make the expression of your process / problem simpler?
OO SolutionOO Solution
If you can express your problem or process in terms of objects and interrelations among them you have an abstract OO solution. Good OO design is such that it makes this OO solution look simple.
Then coding amounts to filling in blanks in method and property implementations.
OO Example: Email ValidationOO Example: Email Validation
Problem: Validate email addressSolution: Define Email class that has an
IsValid() method.
E.g.
if ( Email(“[email protected]”).IsValid() ) …
And you are done!
But what does IsValid() do??
Email: OO DecompositionEmail: OO Decomposition
Email is comprised of LocalPart and Domain.Email is valid when:- It can be parsed into LocalPart and Domain- and when both are valid.
Email => LocalPart@Domain
bool Email::IsValid(){ return Parse() && LocalPart.IsValid() && Domain.IsValid();}
* Email class needs Parse() method LocalPart and Domain member classes.
Domain: OO DecompositionDomain: OO Decomposition
Email is comprised of LocalPart and Domain.Email is valid when:- It can be parsed into LocalPart and Domain- and when both are valid.
Email => LocalPart@Domain
bool Email::IsValid(){ return Parse() && LocalPart.IsValid() && Domain.IsValid();}
* Email class needs Parse() method LocalPart and Domain member classes.
Subdomain and TLD RelationSubdomain and TLD Relation
TLD is a special case of Subdomain. Namely TLD is a subdomain to which additional validation rules apply (e.g. the list of TLD values is determined by ICANN).
Therefore these objects are related. In fact Subdomain is a base class for TLD. TLD::IsValid() is inherited and overriden:
bool TLD::IsValid(){ return Subdomain::IsValid() && InIcanList();}
Email: Fill In the BlanksEmail: Fill In the Blanks
Implement Email::Parse(), Domain::Parse(), Subdomain::IsValid(), TLD::InIcannList().
But even with these methods blank you have an abstract solution that is correct in principle and easy to grasp.
Use Cases: Tool of OO DesignUse Cases: Tool of OO Design
Pertain to requirement elicitation, help understand the way system/object us used.
Use cases describe a dialog between an object and an actor, which could be a user, a device or an external system.
Use cases can be expressed graphically (e.g. via UML) or textually as “scenario scripts”.
In principle a requirement for any process can be given as a comprehensive collection of use cases.
When the system is complete the use cases can provide a basis for acceptance testing.
Use Cases DiagramsUse Cases Diagrams
Actor: entity interacting with object
Use Case: depiction of functionality
Extension: extends the case to illustrate a different or deeper perspective
Use: application / re-uses of the already-defined case.
Use Cases Diagram ExampleUse Cases Diagram Example
Start by listing a sequence of steps a user might take in order to complete an action.
For example a user placing an order with a sales company might follow these steps:•Browse catalog and select items•Call sales representative. •Supply shipping information. •Supply payment information. •Receive conformation number from salesperson
Use Cases QuestionsUse Cases Questions
What actors pertain to the use the object?
What actors / systems are needed for the object to perform its functions?
What external systems send / receive information to / from the object?
Answering these helps make the use cases complete.
Use Cases ChecksUse Cases Checks
Is the terminology consistent? I.e. does everyone use the same terms to describe the same entity, actor or action?
Do the activities match perspectives and are they consistent?
Are the interactions clear and complete?Are there missing interactions?Are there any redundant activities or actors?Is it clear where each activity starts and ends?
OO System DesignOO System Design
After identifying entities (object candidates) in requirements and expressing their interrelations via use cases we need to see what entities share common characteristics.
Then we can express these common traits in a base class.
However, it is conceivable that the identified objects are too dissimilar. But we still can go with OO design as long as the functionality we identified is tightly coupled to the objects.
OO System Design, cont’dOO System Design, cont’d
Actions documented in use cases and in specifications are good method candidates.
Permanent data and state information are properties candidate.
Object RelationshipsObject Relationships
Association: classes appear together, and the relationship is preserved for some time.
Aggregation: one class is a part (i.e. member) of another class.
Dependency: changes to the definition of one class affect the other (not a good idea for classes, OK for packages).
OO Program DesignOO Program Design
First Steps:1) Declaring classes outlined in specification2) Declaring methods according to interface
specification3) Building an abstract solution operating with
empty methods and incomplete classes4) Making sure that your abstract solution is
correct in principle and5) Filling the blanks (method implementations)
OO Program Design, cont’dOO Program Design, cont’d
Filling in the blanks:• Creating additional (utility) classes
that are not described in specification• Creating additional (private) methods
and (private) data members• Implementing solution in a hierarchal
way providing more and more implementation details with each step.
OO Program Design, cont’dOO Program Design, cont’d
Finding and Resolving Problems:- You may be using previously developed
(e.g. reusable) or 3rd party objects that are not fully compatible or require modification / tuning – Drop reusable code? Modify design?
- You may discover that object interfaces listed in specification are inadequate or inconvenient and need modification – amend spec
- You may find inconsistencies or omissions in specification (as well as flaws in the requirements) - amend spec / requirement
OO Program RecommendationsOO Program Recommendations
- Use private to hide all you can- Provide get-accessors for read-only properties- Indicate const methods and mark read-only
parameters as such- Avoid using output parameters (use return values
instead)- Try to minimize state information in favor of passing
additional parameters- Use static (early) binding in favor of late- Throw exceptions in favor of error codes- Never use global objects / global variables- Always follow consistent and predictable coding
patterns- Workout a reusable framework if working on similar
projects
Data Management DesignData Management Design
How do you store and recover persistent objects?
We may need a data model (and a data modeler as well as database administrator in developer team).
Relational data always needs to be properly constrained!
Asynchronous TasksAsynchronous Tasks
Is our process event driven or time driven? Or is it sequential?
If our process is event driven and involves communicating object state changes there are two approaches:
- Global Observer: monitors state changes of all objects involved and issues notifications for dependent objects
- Concrete Observer: each object monitors its own subject
OO Design MeasuresOO Design Measures
Provide numeric measure of qualities of your OO design in order to optimize:
- Number of base classes- Density of utility classes- Specialization Index:
SI = Overridden*level/methods- Methods per class- Weighted methods per class (account for
code length-complexity)- Levels of inheritance- Lack of cohesion
ReadingReading
Chapter 6 in Pfleeger;
Chapter 10 in my book.