Transcript Advanced Object-Oriented Analysis & Design

Advanced Object-Oriented Analysis & Design
Dr. M.E. Fayad, Professor
Computer Engineering Department, Room #283I
College of Engineering
San José State University
One Washington Square
San José, CA 95192-0180
http://www.engr.sjsu.edu/~fayad
Fall 2003
SJSU -- CmpE
L13-S1
Design Heuristics - 2
Lesson 13:
Object-Oriented
Design Heuristics -2
2
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S2
Design Heuristics - 2
Lesson Objectives

Overview of Previous Lecture
 Discuss the following:
Objectives
– Macho Class Problem
– Interesting Design Problems
– Topology Which Needs Accessor Methods
– The Common Traps of Controller Classes
– Many more!!!!
3
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S3
Design Heuristics - 2
A Useful Analogy From Telephony (1)



When designing a telephone system for the
United States we might suggest putting one big
switch in Chicago and connecting every phone
to it. (assume wire is free).
The obvious problem is that if anything happens
to Chicago, the entire phone system is down.
We want to “distribute the system intelligence”
for fault tolerance.
4
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S4
Design Heuristics - 2
A Useful Analogy From Telephony (2)
 Since
we want to distribute the system
intelligence let us propose a new phone
system.
 We will connect each phone to every
other phone in each of other houses.
 The obvious problem here is the
complexity of the system is so great it
prohibits us from adding a new phone.
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S5
5
Design Heuristics - 2
A Useful Analogy From Telephony (3)





Fall 2003
We clearly want to distribute the system intelligence for
fault tolerance, but not too much because it will add too
much complexity.
The same is true in OO design.
Fortunately for telephony system there is the useful
number of call density to determine how the distribution
should take place.
In this case, there is analogy in the domain of OO design.
This leads us to two largest problems plaguing OO
designers: the “Macho Class” Problem and the
“Proliferation of Classes” Problem.
SJSU – CmpE
M.E. Fayad
L13-S6
6
Design Heuristics - 2
Comparison of Macho Class & Overly Distributed
Topologies
Overly Distributed System
Macho Class
Fall 2003
SJSU – CmpE
7
M.E. Fayad
L13-S7
Design Heuristics - 2
The Macho Class Problem
 A Behavior
 A Data
Macho Class
Structure Macho Class
8
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S8
Design Heuristics - 2
A Behavior Macho Class

The problem Occurs when a designer misses the centralized
control mechanism of action-oriented paradigm and attempts
to capture it in a class.

The result is a central brain class talking via accessor
methods (i, e. gets and sets) to a number of uninteresting
data structures.
class1
Macho class
get_y()
get_q()
class2
Fall 2003
set_result()
get_x()
get_z()
class3
SJSU – CmpE
class5
class4
M.E. Fayad
L13-S9
9
Design Heuristics - 2
A Data Structure Macho Class

The problem Occurs when designers are migrating a legacy system
to an OO application.

The legacy system has a global data block being access by many of
the system’s functions.

The designers wrap the data structure in a class with an interface of
accessor methods and then collect the functions into groups within
controller classes
controller
class1
get_x()
Macho class
get_y()
get_q()
controller
class2
Fall 2003
set_result()
get_z()
controller
class3
SJSU – CmpE
controller
class5
controller
class4
M.E. Fayad
L13-S10
10
Design Heuristics - 2
Legacy Systems: A Definition

Legacy Software is any preexisting software
that must be replaced by, incorporated into, or
interfaced with software that is currently being
developed.

Legacy software is typically not OO and the
use of legacy software on projects developing
OO software can cause problems due to the
impedance
mismatch
between
different
structures of the software.
11
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S11
Design Heuristics - 2
The Accessor Method Debate (1)

An accessor method is any relatively standard
small and simple method that is used to either
get or set the value of an instance attribute

Synonyms: Accessing Method, Accessing
Operation, Accessor Operation.

Contrast with: Accessor Message or Accessing
Message

Accessor Message is any message used to get
or set the value of instance attribute.
12
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S12
Design Heuristics - 2
The Accessor Method Debate (2)

Examples from patterns
discussion (e-mail) group

A message stated that the
following class is dangerous
since it gives away
implementation details.

The Point Class
int x;
int y;
Another messages agreed with
this premise but argued that
they are useful, necessary, and
therefore valid.
Fall 2003
SJSU – CmpE
M.E. Fayad
get_x()
get_x()
get_y()
set_y()
13
L13-S13
Design Heuristics - 2
The Accessor Method Debate (3)

The point of this example is that the Point class does
not give a way implementation details.

By definition a method hides the details.

All this Point class is stating is that it possess the
abstraction notion of a rectangular coordinate system.

The actual implementation might be an integer radius
and a real number theta (polar coordinates).

The get_x() method simply multiplies radius and the
cosine of theta.
14
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S14
Design Heuristics - 2
The Accessor Method Debate (4)

The real questions are:
– Who is getting x and y?

Beware of people who state that it is often
useful to pull an object X from an object Y so
that object Z can use it directly.

We ask an ATM machine to withdraw $100.00
for us, we don’t ask it for its cash dispenser
and then use the dispenser directly.
15
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S15
Design Heuristics - 2
A Topology Which Needs Accessor Methods

OO models & User Interfaces

Make OO independent of its user interface.

The result is use of accessor methods defined on the model
classes by the user interface classes.

The topology does not advocate accessor method calls
between the classes of the model, only those between the
model and its user interface
OO Model
get/set messages
User Interface
16
The Model-Interface Application Topology
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S16
Design Heuristics - 2
The Common Traps of Controller Classes (1)

There are several places in design where controller
classes seem to provide us with solution to a difficult
problem.

These include the migration of legacy systems and the
need to hide portions of a class’s public interface.

Consider the following legacy system for handling call
processing.
17
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S17
Design Heuristics - 2
The Common Traps of Controller Classes (2)
CallProcessingBlock
A Legacy Call
Processing System
data1
data2
data3
Func1()
Func7()
Func3()
Func2()
Func5()
Func6()
Func4()

A collection of global data with separate global functions taking direct
access.

To migrate this system to OO, controller classes seem to ease the job.
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S18
18
Design Heuristics - 2
Controller Classes & the Migration of Legacy Systems (1)

The functions can be grouped into controller
classes and the global data can be
encapsulated into a class with accessor
methods.

The problem with this design is that we have
lost the ability to ask, “I have changed the
CallProcessing class, who need to be told?”

This is a violation of encapsulation.
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S19
19
Design Heuristics - 2
Controller Classes & the Migration of Legacy Systems (2)
The CallProcessing Class
CallProcessingBlock
Poor
Migration
Func1()
data1
data2
data3
get_data1()
set_data1()
get_data2()
set_data2()
get_data3()
set_data3()
Func3()
Func2()
ContollerClass1
Func7()
Func5()
Func6()
Func4()
ContollerClass3
ContollerClass2
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S20
20
Design Heuristics - 2
Controller Classes & the Migration of Legacy Systems (3)
CallProcessingBlock
A Better
Migration
Func1()
Func3()
Func2()
Func7()
Func5()
Func6()
TelephonyClass1
Func4()
TelephonyClass3
TelephonyClass2
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S21
21
Design Heuristics - 2
Controller Classes & the Migration of Legacy Systems (4)

A more difficult

But more correct solution

Solution is to break up the data structure,
encapsulating each part with its related
behavior.
22
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S22
Design Heuristics - 2
Controller Classes & Hiding Portions of Public Interface
(1)

Another mistaken use of controller classes occurs when
designers of reusable frameworks need to address public
interface issues of two or more product groups.

Consider the following design produced by multimedia
company. This company had two product groups which
built there products based on a single framework.

Fall 2003
The framework captured the fact that all of the company’s
products were based on the abstract notion of a
composition.
SJSU – CmpE
M.E. Fayad
L13-S23
23
Design Heuristics - 2
Controller Classes & Hiding Portions of Public Interface
(2)

A composition was a bunch of tracks (many derived classes
of track), each track was a bunch of clips (many derived
classes of clip), and each clip was associated with some
piece of media.

The play application needed operations P, Q, and R while the
editor application needed operations X, Y, and Z.

How do I prevent each application from seeing the other
classes portion of the interface?
24
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S24
Design Heuristics - 2
Controller Classes & Hiding Portions of Public Interface
(3)
Reuse of Entity Classes Via Controller Classes
The Composition
Entity Class
P, Q, R
X, Y, Z
gets/sets for the support of
P, Q, R, X, Y, Z
The Editing
Controller
The Player
Controller
The Editing
Application
The Player
Application
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S25
25
Design Heuristics - 2
Controller Classes & Hiding Portions of Public Interface
(4)


The problem with the controller class design is that we have
now given up encapsulation in order to minimize access to
the public interface of composition.
The following design maintains this encapsulation.
A Better Design for
The Composition Class
The Composition
Entity Class
P, Q, R, X, Y, Z
Only uses X, Y, and Z
Only uses P, Q, and R
The Editing
Application
The Player
Application
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S26
26
Design Heuristics - 2
Controller Classes & Hiding Portions of Public Interface
(5)

If minimizing access to public interface of
composition is very important, then it is
possible to encapsulate the Composition
class in an EditComp and PlayComp
classes.

This creates two new encapsulated classes
which only exist to minimize public interface
access.
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S27
27
Design Heuristics - 2
Heuristics for Avoiding Macho Classes (1)

Heuristic #1: Distribute horizontal system intelligence as
uniformly as possible, i.e. the top level classes in a
design should share the work uniformly.

Heuristic #2: Beware of classes that have many
accessor methods defined in their public interfaces.

Heuristic #3: Spin off non-related information into
another class, i.e. non-communicating behavior.
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S28
28
Design Heuristics - 2
Heuristics for Avoiding Macho Classes (2)

Heuristic #4: Most of the methods of a class should use
most of the data most of the time.

Heuristic #5: Keep related data and behavior in one
place.

Heuristic #6: Be suspicious of any class in your system
whose name contains the substrings driver, system,
subsystem, or manager.
Fall 2003
SJSU – CmpE
29
M.E. Fayad
L13-S29
Design Heuristics - 2
The Proliferation of Classes Problem (1)

There are ten heuristics which govern the avoidance of class
proliferation. Two causes are easy to avoid since they lead to
an explosion in number of classes. A third causes a toggling
of data types which is also easily identified.
Heuristic # 1
Eliminate irrelevant classes from your design.

This heuristic warns the designer to be suspicious of any
class which adds no meaningful behavior to the design.
However, there are some designs which use irrelevant classes
for flexibility. Consider the following design as an example.
30
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S30
Design Heuristics - 2
The Proliferation of Classes Problem (2)
New Employee
Salary
Sicktime
Medical Plan
compute_taxes()
benefits()
inheritance
Vacation
Dental Plan
Car
benefits()
31
Full Employee
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S31
Design Heuristics - 2
The Proliferation of Classes Problem (3)

There exists a heuristic which argues that one
should not inherit from a concrete class(i.e. a class
which can build objects of itself).

This heuristic is concerned about flexibility. What if
we decide to add an orientation to all new
employees.

The full employees do not need this but are forced to
accept it. This inevitably leads to a break in the
specialization relationship (inheritance).
32
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S32
Design Heuristics - 2
The Proliferation of Classes Problem (4)

We could transform the design such that it obeys the “Always
inherit from an abstract class” heuristic.
Salary
Sicktime
Medical Plan
compute_taxes()
benefits()
inheritance
Fall 2003
Orientation
Vacation
Dental Plan
Car
New Employee
Full Employee
SJSU – CmpE
M.E. Fayad
benefits()
33
L13-S33
Design Heuristics - 2
The Proliferation of Classes Problem (5)

How ever; if we mindless follow this heuristic, and we really
cannot see any break in the specialization relationship, then
NewEmployee would end up and irrelevant class.

The ramification of this issue is that there is no way to satisfy
both heuristics. One is worried about extensibility while the
other is worried about the complexity.

Try to answer the following question and you begin to
understand why a prioritized listing of the heuristic cannot be
done.

What’s more important, reducing complexity or increasing
flexibility ?
34
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S34
Design Heuristics - 2
The Proliferation of Classes Problem (6)
Heuristic # 2

Eliminate classes that are outside the system.

Some years ago I worked with a company designing a product
registration system.

The company received postcards filled out by consumers who
recently bought a product such as a blender. The data would be
entered and sold to a variety of vendors.

Questions like, “Is a blender a class?” were common. Clearly blenders
are objects which belongs to the blender class they have a hidden
implementation and a well defined public interface( chop, grind, puree,
etc.).

However, they are not inside the system.
Fall 2003
SJSU – CmpE
35
M.E. Fayad
L13-S35
Design Heuristics - 2
The Proliferation of Classes Problem (7)

While such a real world domain might make this
heuristic seem a bit trivial, once a designer enters a
more abstract domain then he or she makes
equivalent mistakes.

Many argue over the role that a customers plays
within an ATM system.

In another case I have witnessed considerable debate
as to whether the telephone itself is within the domain
of a telephone switching system.
36
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S36
Design Heuristics - 2
The Proliferation of Classes Problem (8)
Heuristic # 3
Do not turn an operation into a class. Be suspicious of any class
which has only one piece of meaningful behavior, especially if
its name is a verb or derived from a verb.

This form of class proliferation is one of the most common.
Action oriented programmers are familiar with the function as
the component of decomposition.

They tend to continue the practice in the object oriented
paradigm.

The prerequisite checker class from the course scheduling
system is a clear example of this as are many controller
classes.
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S37
37
Design Heuristics - 2
The Proliferation of Classes Problem (9)
Heuristic # 4

Beware of irrelevant agent classes.

Agent classes are often added during the analysis phase of
development.

During the design phase many of these agents are found to be
irrelevant and should be removed.
38
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S38
Design Heuristics - 2
The Proliferation of Classes Problem (10)
Heuristic # 5

Be sure that abstraction you modeling is a class and not a role
that classes play.

There are cases where roles should be modeled as their own
class and cases where they are simply a clump of methods in
the public interface of a class.
39
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S39
Design Heuristics - 2
The Proliferation of Classes Problem (11)
Heuristic # 6

When implementing semantic constraints, it is best to
implement them in terms of the class definition.

Often this will lead to a proliferation of classes in which case
the constraint must be implemented in the behavior of the
class, usually, but not necessary in the constructor.

There are cases where roles should be modeled as their own
class and cases where they are simply a clump of methods in
the public interface of a class.
40
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S40
Design Heuristics - 2
The Proliferation of Classes Problem (12)

Imagine that there are four choices of vegetables : peas,
squash, corn and asparagus. How do we disallow peas
and corn as a combination ?
Heuristic # 7

Do not model the dynamic semantics of a class through
the use of the inheritance relationship. An attempt to
model dynamic semantics with a static relationship will
lead to a toggling of types at runtime.
41
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S41
Design Heuristics - 2
The Proliferation of Classes Problem (13)

Heuristic # 8

Do not turn objects of a class into derived classes of
the class.

Be very suspicious of any derived class for which
there is only one instance.
42
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S42
Design Heuristics - 2
The Proliferation of Classes Problem (14)
Heuristic # 9

Do not confuse optional containment with need for
inheritance, modeling optional containment with inheritance
will lead to a proliferation of classes.

Consider the following designs:
1.Dogs have optional tails
2. Houses have optional heating, cooling, electrical and
plumbing systems.
43
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S43
Design Heuristics - 2
The Proliferation of Classes Problem (15)
Heuristic # 10

If you think you need to create new classes at runtime, take a
step back and realize that what you are trying to create are
objects. Now generalize these objects into classes.

Consider the following problem from the domain of securities
trading.

The taxonomy for describing securities is well defined by the
markets themselves. The problem is that securities firms like
to define new securities.
44
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S44
Design Heuristics - 2
The Proliferation of Classes Problem (16)
Security
Bonds
Tax-Free
Zero-Coupon
etc
Fall 2003
Stocks
Lotus
Futures
IBM
Gold
Oil
etc
etc
SJSU – CmpE
45
M.E. Fayad
L13-S45
Design Heuristics - 2
The Proliferation of Classes Problem (17)
This leads to a perceived problem of a need to create new classes at
runtime.
SECURITY
Zero Coupon
Lotus
Gold
Zero Coupon
Zero Lotus
Lotus
Zero Lotus
Gold Zero Lotus
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S46
46
Design Heuristics - 2
The Proliferation of Classes Problem (11)

The real solution is to take a step back and determine that ZeroLotus
and GoldZeroLotus are objects. What class models them ?
Security
Security_list
Security
Ford
Security
Security
47
BasketOfSecurities
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S47
Design Heuristics - 2
Discussion Questions
•
T/F statements
1. Abstract classes are used to generate object instances
2. Legacy Software is any preexisting software that must be
replaced by, incorporated into, or interfaced with software that
is currently being developed
3. Utility class contains global variables and functions.
4. Design patterns identify, name, and describe common and
recurring designs appearing frequently in object-oriented
systems.
•
Fall 2003
48
Define in UML: Abstract Classes, Objects, Metaclasses,
Parameterized Classes, Utility Classes, and Notes
SJSU – CmpE
M.E. Fayad
L13-S48
Design Heuristics - 2
Questions for the Next Lecture
Define:
– Objects
– Notes
– Attributes
– Operations
– Design patterns
– The relationships between classes and
objects.
49
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S49
Design Heuristics - 2
Tasks for Next Lecture
Task 1: Read Chapter the rest of
Chapter 3 UML notation and
terminology definitions.
50
Fall 2003
SJSU – CmpE
M.E. Fayad
L13-S50
Design Heuristics - 2