1. Design Strategies in OO Development
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Design Strategies in OO Development
Identifying objects (and services or operations) is the key to a good OO design.
A class is an explicit abstraction (model) of a problem domain entity.
Abstractions come from the problem domain.
Programming is a modeling activity.
Separation is the division of interface from implementation.
Realization of the principle of information hiding.
Composition views a complex system as an organized collection of simpler parts.
Understanding the interactions (relationships, collaborations, etc.) of the parts is vital.
Generalization is the identification of the shared properties of problem model abstractions and the organized exploitation of same.
Look for quantifiers like "all" and "every".
This diagram represents the principal connections.
Understanding the connections will aid in creating well-designed systems.
Relationships will only be understood after intense study and practice of OOD and OOP.
Structures relate to 3 of the r design strategies.
The forms of generalization relate to all of the SE goals.
Abstraction modeling essential properties
Separation treat what and how independently
Composition building complex structures from simpler ones
Generalization identifying common elements
abstraction
separation
composition
generalization
Design
Strategies
objects
classes
inheritance
templates
design patterns
Software Structures
extensibility
flexibility
reusability
Software Engineering Goals
Kafura
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

2. CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Abstraction
Hills, buildings and cossacks with lances. The artist only shows the essential, distinguishing characteristics of each entity.
Modeling entities (real world or conceptual) in software
An abstraction distills something to its essential properties. The properties that make it what it is and distinguish it from others.
Simplifies complex problems
Only essential aspects should be included:
attributes = properties, characteristics, information
behavoir = actions
When you say “car,” people get a picture of a generic, or “abstract,” thing with certain properties:
wheels, speed, direction, number of passengers, number of axles
and behavior:
accelerate, brake, stop, turn right, turn left, etc.
Modeling entities in software
Only essential aspects should be captured
attributes
behavior
Wassily Kandinski
Cossacks,
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

3. Practical Abstraction
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Practical Abstraction
Practical abstractions. These shapes convey the essential distinguishing characteristics of a male and female (in our society).
Critique??
Kafura
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

4. CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Abstraction
Attribute and behavior identification (usually these are not completely identified in systems analysis/requirements documents):
How is the object described in general?
What parts of the general description are applicable to this problem domain?
What is the minimal description needed for this application?
Tradeoff: capturing more specific attributes and behaviors may result in objects that are more efficient in time/space, but also are less flexible and reusable.
But for software, an abstraction is not a philosophical, ethereal concern.
In development, abstractions are refined throughout the life of a piece of software. We start with hand-made lists, and progress through various formal methods, sometimes using software tools.
The implementation in source code is the ultimate expression of a software abstraction.
Name: to distinguish from other abstractions
Attributes and behavior: the essential elements of an abstraction.
Modeling: what software is all about
Purpose: appropriate abstractions are different for different purposes.
Book example of a salesperson abstraction from two perspectives.
One is the sales system, number of cars sold is important
other is medical system, which couldn’t care less about number sold
Well named: clearly conveys aspects of the abstraction Whether it is meaningful depends on the audience.
Coherent: makes sense
Accurate: contains only the attributes the modeled entity contains. Note VR exception
Minimal: only the attributes needed for the purpose of the abstraction. For example, hair color is irrelevant for a billing system.
Complete: All the attributes and behavior needed for the purpose of the software.
These are all subjective. Judgement through experience are needed.
A named collection of attributes and behavior relevant to modeling a given entity for some particular purpose.
Desirable Properties:
well named name conveys aspects of the abstraction
coherent makes sense
accurate contains only attributes modeled entity contains
minimal contains only attributes needed for the purpose
complete contains all attributes and behavior needed for the purpose
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

5. CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Better Abstractions
These abstractions illustrates properties of a “good” abstraction:
well named (for English-speakers)
coherent
accurate (culture sensitive representations – Scotland?, ME?)
minimal
complete
Is gender an attribute or a behavior or a class??
Depends upon the system in question.
If none of the relevant, modeled behaviors of any of the entities in the system are gender-specific then gender is an attribute.
Otherwise, gender is a class.
MEN
WOMEN
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

6. Mapping Abstraction to Software
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Mapping Abstraction to Software
There is a great danger that abstractions will get lost in programming details. Avoid compromising the abstraction.
There is inevitably a loss of precision and completeness when crossing the first boundary.
No abstraction can capture the entirety of its inspiration.
The designer must determine which attributes and behaviors are essential and which are not.
Ideally, the transition across the second boundary should not involve any loss of precision.
In practice there will be loss of precision here due to limitations of the implementation tools (e.g., type double versus the set of real numbers).
real-world
abstraction
software
entity
attributes
behavior
{data, data,…}
{method, method,…}
Kafura
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

7. Separation of Interface from Implementation
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Separation of Interface from Implementation
What is to be done versus How it is done
what/how, goal/plan, policy/mechanism, product/process, ends/means
Simpler to express what versus how.
Requirements analysis specifies what, programmers implement the how.
In programming, the independent specification of an interface and one or more implementations of that interface.
Interface
Implementation
visible
hidden
What is to be done vs
How it is to be done
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

8. Interchangeability of Implementations
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Interchangeability of Implementations
Flexibility. Different implementations can satisfy the same interface.
Perhaps the implementations differ in price, reliability, location, etc.
Implementations of the same interface are called “plug compatible”
Allows the creation of multiple implementations with a common interface.
For example: a List ADT could use a dynamic linked list or a dynamic array for the underlying physical data structure. In either case, the same interface would be appropriate (and the user need not be concerned with the underlying structure in many cases).
interface
implementation2
implementation1
Implementations that share a common interface are said to be “plug compatible”.
They may differ in algorithmic complexity, reliability, platform dependencies, etc.
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

9. Specificity of Interface
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Specificity of Interface
An implementation can satisfy more than one interface.
This allows the isolation of restricted set used in one situation versus another
Suppose there is a more efficient implementation of TextInterface that we want to use in a critical part of the system.
Also allows a single implementation to support multiple interfaces.
This allows the isolation of restricted set used in one situation versus another
LList
implementation
Stack
For example, we could have a very general List ADT that supported both standard List operations, and also Stack operations. By “subsetting” the functionality of the ADT into separate interfaces, we could provide both categories of operation, in a natural way, without duplication of shared code.
In essence, we view the implementation as a library of related widgets.
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

10. Mapping Abstraction to Software in OO
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Mapping Abstraction to Software in OO
You can model an abstraction in any software language. Prior to O-O, the notion of encapsulating data and operations together was called an Abstract Data Type.
But O-O facilitates modeling these kinds of abstractions by using Classes and Objects.
real-world
abstraction
OO software
entity
attributes
behavior
{data, data,…}
{method, method,…}
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

11. General Structure of a Class
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
General Structure of a Class
The software model of an abstraction.
Class is the definition of the attributes and behavior with implementation.
“Class” is used to convey that it represents all members of a group
Separation: two parts to a class, public interface, private data and implementation.
Hiding data is important so that other developers using the class do not erroneously change it. Hide it and they cannot get to it.
Private implementation also hides the algorithm. This is sometimes called “encapsulation.”
Class: a named software representation for an abstraction that separates the implementation of the representation from the interface of the representation.
Some methods may be private, in fact this is common.
Some data may be public, this should not be common.
Some OO languages do not use classes. E.g., “Self” uses prototypes
class: a named software representation for an abstraction that separates the implementation of the representation from the interface of the representation
A class models an abstraction, which models an entity (possibly “real”).
A class represents all members of a group of objects (“instances” of the class).
A class provides a public interface and a private implementation.
The hiding of the data and “algorithm” from the user is important. Access restrictions prevent idle or malicious alterations.
private
public
className
{data, data, ….}
{method,method, …}
typical organization
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

12. General Structure of an Object
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
General Structure of an Object
A specific member of a class.
Interface and Implementation are separate
The object “encapsulates” its data
Encapsulation: in o-o programming, the restriction of access to data within an object to only those members defined by the object’s class.
Multiple objects are created from a single class definition.
Object: A distinct instance of a given class that encapsulates its implementation details and is structurally identical to all other instances of that class.
object: a distinct instance of a given class that encapsulates its implementation details and is structurally identical to all other instances of that class
An object “encapsulates” its data and the operations that may be performed on that data.
An object’s private data may ONLY be accessed via the member functions defined within the object’s class.
An object hides details of representation and implementation from the user.
code .
data
method
implementation
interface
C++ note:
Privacy restrictions are enforced at the class level, NOT the object level.
That is, if A and B are of the same type, and A knows B’s name, then A can access the private members of B directly.
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

13. Separation and Classes
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Separation and Classes
If we have two different classes, objects of each can see only the (public) interfaces of the objects of the other.
class A implementation provides methods
class B implementation can use class A methods identified in the class A interface
class A interface identifies available methods
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

14. Multiple Instances of a Class
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Multiple Instances of a Class
Each instance, or object, usually has different values for the class-defined properties.
Class=Factory Objects=products
Side point (if there’s time)
When developing abstractions, or classes, it may help to think of them as people-like entities with responsibilities and collaborators .
Responsibilities of knowing (respond with information to a query)
Responsibilities of doing (act on something, transform, move, sort, etc.)
Collaborators: associated objects in the system with their own responsibilities (association is next week)
SalesPerson
private
public
Name
commissionRate
totalSales
sellCar
reportSales
Joe Hokie
16% $
Jill Hokie $
Each instance, or object, usually has different values for the class-defined properties.
Class = Factory Objects = Products
When developing abstractions, or classes, it may help to think of them as people-like entities with responsibilities and collaborators.
Responsibilities of knowing (respond with information to a query)
Responsibilities of doing (act on something, transform, move, sort, etc.)
Collaborators: associated objects in the system with their own responsibilities
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ

15. Software Engineering Goals
CS 2704 Object Oriented Software Design and Construction
May 5, 2019
Software Engineering Goals
Objects and classes help programmers achieve a primary software-engineering goal: reusability
A single class is used repeatedly to create multiple object instances.
More importantly, encapsulation prevents other developers from inadvertently modifying an object’s data.
Separation allows different implementations to be used for an interface.
Objects and classes help programmers achieve a primary software-engineering goal: reusability
A single class is used repeatedly to create multiple object instances.
More importantly, encapsulation prevents other developers from inadvertently modifying an object’s data.
Separation allows different implementations to be used for an interface.
objects
classes
inheritance
templates
design patterns
Software Structures
extensibility
flexibility
reusability
Software Engineering Goals
OO Design Introduction
Computer Science Dept Va Tech January 2002
© McQuain WD & Keller BJ