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(“max@ultramax.com”).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.