© M.E. Fayad 1997-2006 SJSU -- CmpE
Software System Engineering
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
L6-2-S2 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
2
Lesson 6-2: Object-Oriented
Design Heuristics -2
L6-2-S3 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
Lesson Objectives
3
Overview of Previous Lecture Discuss the following: – Macho Class Problem – Interesting Design Problems – Topology Which Needs Accessor Methods – The Common Traps of Controller Classes – Many more!!!!
L6-2-S4 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
4
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.
L6-2-S5 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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. 5
A Useful Analogy From Telephony (2)
L6-2-S6 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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. 6
A Useful Analogy From Telephony (3)
L6-2-S7 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
7
Comparison of Macho Class & Overly Distributed Topologies
Macho Class
Overly Distributed System
L6-2-S8 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
A Behavior Macho Class
A Data Structure Macho Class
8
The Macho Class Problem
L6-2-S9 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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.
9
A Behavior Macho Class
Macho class class5 class1
class2 class3 class4
set_result()
get_z()
get_x()
get_y() get_q()
L6-2-S10 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
10
A Data Structure Macho Class
Macho class controller class1
set_result()
get_z()
get_x()
get_y() get_q()
controller class2
controller class3
controller class4
controller class5
L6-2-S11 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
L6-2-S12 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Accessor Method Debate (1)
L6-2-S13 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
Examples from patterns discussion (e-mail) group
A message stated that the following class is dangerous since it gives away implementation details.
Another messages agreed with this premise but argued that they are useful, necessary, and therefore valid. 13
The Accessor Method Debate (2)
int x; int y;
The Point Class
get_x() get_x() get_y() set_y()
L6-2-S14 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Accessor Method Debate (3)
L6-2-S15 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Accessor Method Debate (4)
L6-2-S16 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
16
A Topology Which Needs Accessor Methods
OO Model User Interface get/set messages
The Model-Interface Application Topology
L6-2-S17 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Common Traps of Controller Classes (1)
L6-2-S18 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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. 18
The Common Traps of Controller Classes (2)
data1 data2 data3
Func2()
Func1()
Func3()
Func4()
Func5()
Func6()
Func7()
A Legacy Call Processing System
CallProcessingBlock
L6-2-S19 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
19
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.
L6-2-S20 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
20
Controller Classes & the Migration of Legacy Systems (2)
get_data1() set_data1() get_data2() set_data2() get_data3() set_data3()
data1 data2 data3
CallProcessingBlock
Func2()
Func1() Func3()
Func4()
Func5()
Func6()
Func7()
ContollerClass1
ContollerClass2 ContollerClass3
The CallProcessing Class
Poor Migration
L6-2-S21 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
21
Controller Classes & the Migration of Legacy Systems (3)
CallProcessingBlock
Func2()
Func1() Func3()
Func4()
Func5()
Func6()
Func7()
TelephonyClass1
TelephonyClass2 TelephonyClass3
A Better Migration
L6-2-S22 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
22
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.
L6-2-S23 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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.
The framework captured the fact that all of the company’s products were based on the abstract notion of a composition. 23
Controller Classes & Hiding Portions of Public Interface (1)
L6-2-S24 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
Controller Classes & Hiding Portions of Public Interface (2)
L6-2-S25 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
25
Controller Classes & Hiding Portions of Public Interface (3)
The Composition Entity Class
The Player Controller
P, Q, R
The Player Application
The Editing Controller
X, Y, Z
The Editing Application
gets/sets for the support of P, Q, R, X, Y, Z
Reuse of Entity Classes Via Controller Classes
L6-2-S26 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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.
26
Controller Classes & Hiding Portions of Public Interface (4)
The Composition Entity Class
The Player Application
The Editing Application
Only uses P, Q, and R Only uses X, Y, and Z
P, Q, R, X, Y, Z A Better Design for
The Composition Class
L6-2-S27 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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. 27
Controller Classes & Hiding Portions of Public Interface (5)
L6-2-S28 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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. 28
Heuristics for Avoiding Macho Classes (1)
L6-2-S29 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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. 29
Heuristics for Avoiding Macho Classes (2)
L6-2-S30 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (1)
L6-2-S31 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
31
The Proliferation of Classes Problem (2)
Vacation Dental Plan
Car
Salary Sicktime Medical Plan
inheritance
Full Employee
benefits()
compute_taxes() benefits()
New Employee
L6-2-S32 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (3)
L6-2-S33 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
We could transform the design such that it obeys the “Always inherit from an abstract class” heuristic.
33
The Proliferation of Classes Problem (4)
Vacation Dental Plan
Car
Salary Sicktime
Medical Plan
Orientation
New Employee Full Employee
compute_taxes() benefits()
benefits()
inheritance
L6-2-S34 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (5)
L6-2-S35 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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.
35
The Proliferation of Classes Problem (6)
L6-2-S36 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (7)
L6-2-S37 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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. 37
The Proliferation of Classes Problem (8)
L6-2-S38 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (9)
L6-2-S39 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (10)
L6-2-S40 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (11)
L6-2-S41 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (12)
L6-2-S42 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (13)
L6-2-S43 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (14)
L6-2-S44 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
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
The Proliferation of Classes Problem (15)
L6-2-S45 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
45
The Proliferation of Classes Problem (16)
Security
Futures Stocks Bonds
Tax-Free Zero-Coupon Lotus IBM Gold Oil
etc etc etc
L6-2-S46 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
46
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
Zero Lotus
Zero Coupon Lotus
Zero Lotus Gold
Gold Zero Lotus
L6-2-S47 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
47
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 ?
Ford
Security
Security Security Security
BasketOfSecurities
Security_list
L6-2-S48 Design Heuristics - 2 © M.E. Fayad 1997-2006 SJSU – CmpE M.E. Fayad
• 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.
• Define in UML: Abstract Classes, Objects, Metaclasses, Parameterized Classes, Utility Classes, and Notes 48
Discussion Questions