1. Software System Engineering
11/28/2018
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
© M.E. Fayad
SJSU -- CmpE

2. Lesson 6-2: Object-Oriented Design Heuristics -2
11/28/2018
Lesson 6-2:
Object-Oriented
Design Heuristics -2 2
© M.E. Fayad
SJSU – CmpE M.E. Fayad

3. 3 Lesson Objectives Overview of Previous Lecture
11/28/2018
Lesson Objectives
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!!!! 3
© M.E. Fayad
SJSU – CmpE M.E. Fayad

4. A Useful Analogy From Telephony (1)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

5. A Useful Analogy From Telephony (2)
11/28/2018
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. 5
© M.E. Fayad
SJSU – CmpE M.E. Fayad

6. A Useful Analogy From Telephony (3)
11/28/2018
A Useful Analogy From Telephony (3)
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

7. Comparison of Macho Class & Overly Distributed Topologies
11/28/2018
Comparison of Macho Class & Overly Distributed Topologies
Overly Distributed System
Macho Class 7
© M.E. Fayad
SJSU – CmpE M.E. Fayad

8. The Macho Class Problem
11/28/2018
The Macho Class Problem
A Behavior Macho Class
A Data Structure Macho Class 8
© M.E. Fayad
SJSU – CmpE M.E. Fayad

9. 11/28/2018
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.
set_result()
get_x()
class5
class1
Macho class
get_y()
get_z()
get_q() 9
class2
class3
class4
© M.E. Fayad
SJSU – CmpE M.E. Fayad

10. A Data Structure Macho Class
11/28/2018
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
set_result()
get_x()
controller
class5
controller
class1
Macho class
get_y()
get_z()
get_q() 10
controller
class3
controller
class4
controller
class2
© M.E. Fayad
SJSU – CmpE M.E. Fayad

11. Legacy Systems: A Definition
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

12. The Accessor Method Debate (1)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

13. The Accessor Method Debate (2)
11/28/2018
The Accessor Method Debate (2)
Examples from patterns discussion ( ) 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.
The Point Class
get_x()
get_y()
set_y()
int x;
int y; 13
© M.E. Fayad
SJSU – CmpE M.E. Fayad

14. The Accessor Method Debate (3)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

15. The Accessor Method Debate (4)
11/28/2018
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 $ for us, we don’t ask it for its cash dispenser and then use the dispenser directly. 15
© M.E. Fayad
SJSU – CmpE M.E. Fayad

16. A Topology Which Needs Accessor Methods
11/28/2018
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
User Interface
get/set messages 16
The Model-Interface Application Topology
© M.E. Fayad
SJSU – CmpE M.E. Fayad

17. The Common Traps of Controller Classes (1)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

18. The Common Traps of Controller Classes (2)
11/28/2018
The Common Traps of Controller Classes (2)
CallProcessingBlock
A Legacy Call
Processing System
data1
data2
data3
Func1()
Func7()
Func3()
Func5()
Func6()
Func2()
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. 18
© M.E. Fayad
SJSU – CmpE M.E. Fayad

19. Controller Classes & the Migration of Legacy Systems (1)
11/28/2018
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. 19
© M.E. Fayad
SJSU – CmpE M.E. Fayad

20. Controller Classes & the Migration of Legacy Systems (2)
11/28/2018
Controller Classes & the Migration of Legacy Systems (2)
The CallProcessing Class
get_data1()
set_data1()
get_data2()
set_data2()
get_data3()
set_data3()
Poor
Migration
CallProcessingBlock
data1
data2
data3
Func1()
Func3()
Func7()
Func5()
Func2()
Func6() 20
Func4()
ContollerClass1
ContollerClass3
ContollerClass2
© M.E. Fayad
SJSU – CmpE M.E. Fayad

21. Controller Classes & the Migration of Legacy Systems (3)
11/28/2018
Controller Classes & the Migration of Legacy Systems (3)
A Better
Migration
CallProcessingBlock
Func1()
Func3()
Func7()
Func5()
Func2()
Func6() 21
Func4()
TelephonyClass1
TelephonyClass3
TelephonyClass2
© M.E. Fayad
SJSU – CmpE M.E. Fayad

22. Controller Classes & the Migration of Legacy Systems (4)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

23. Controller Classes & Hiding Portions of Public Interface (1)
11/28/2018
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.
The framework captured the fact that all of the company’s products were based on the abstract notion of a composition. 23
© M.E. Fayad
SJSU – CmpE M.E. Fayad

24. Controller Classes & Hiding Portions of Public Interface (2)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

25. Controller Classes & Hiding Portions of Public Interface (3)
11/28/2018
Controller Classes & Hiding Portions of Public Interface (3)
Reuse of Entity Classes Via Controller Classes
The Composition
Entity Class
gets/sets for the support of
P, Q, R, X, Y, Z
X, Y, Z
P, Q, R
The Editing
Controller
The Player
Controller 25
The Editing
Application
The Player
Application
© M.E. Fayad
SJSU – CmpE M.E. Fayad

26. Controller Classes & Hiding Portions of Public Interface (4)
11/28/2018
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 26
The Editing
Application
The Player
Application
© M.E. Fayad
SJSU – CmpE M.E. Fayad

27. Controller Classes & Hiding Portions of Public Interface (5)
11/28/2018
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. 27
© M.E. Fayad
SJSU – CmpE M.E. Fayad

28. Heuristics for Avoiding Macho Classes (1)
11/28/2018
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. 28
© M.E. Fayad
SJSU – CmpE M.E. Fayad

29. Heuristics for Avoiding Macho Classes (2)
11/28/2018
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. 29
© M.E. Fayad
SJSU – CmpE M.E. Fayad

30. The Proliferation of Classes Problem (1)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

31. The Proliferation of Classes Problem (2)
11/28/2018
The Proliferation of Classes Problem (2)
New Employee
Salary
Sicktime
Medical Plan
compute_taxes()
benefits()
inheritance
Vacation
Dental Plan
Car
benefits() 31
Full Employee
© M.E. Fayad
SJSU – CmpE M.E. Fayad

32. The Proliferation of Classes Problem (3)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

33. The Proliferation of Classes Problem (4)
11/28/2018
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
Orientation
Vacation
Dental Plan
Car
benefits() 33
New Employee
Full Employee
© M.E. Fayad
SJSU – CmpE M.E. Fayad

34. The Proliferation of Classes Problem (5)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

35. The Proliferation of Classes Problem (6)
11/28/2018
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. 35
© M.E. Fayad
SJSU – CmpE M.E. Fayad

36. The Proliferation of Classes Problem (7)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

37. The Proliferation of Classes Problem (8)
11/28/2018
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. 37
© M.E. Fayad
SJSU – CmpE M.E. Fayad

38. The Proliferation of Classes Problem (9)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

39. The Proliferation of Classes Problem (10)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

40. The Proliferation of Classes Problem (11)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

41. The Proliferation of Classes Problem (12)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

42. The Proliferation of Classes Problem (13)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

43. The Proliferation of Classes Problem (14)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

44. The Proliferation of Classes Problem (15)
11/28/2018
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
© M.E. Fayad
SJSU – CmpE M.E. Fayad

45. The Proliferation of Classes Problem (16)
11/28/2018
The Proliferation of Classes Problem (16)
Security
Bonds
Stocks
Futures
Tax-Free
Zero-Coupon
Lotus
IBM
Gold
Oil
etc
etc 45
etc
© M.E. Fayad
SJSU – CmpE M.E. Fayad

46. The Proliferation of Classes Problem (17)
11/28/2018
The Proliferation of Classes Problem (17)
This leads to a perceived problem of a need to create new classes at runtime.
SECURITY
Gold
Zero Coupon
Lotus
Zero Lotus
Zero Coupon
Lotus 46
Zero Lotus
Gold Zero Lotus
© M.E. Fayad
SJSU – CmpE M.E. Fayad

47. The Proliferation of Classes Problem (11)
11/28/2018
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
Ford
Security
Security
Security 47
BasketOfSecurities
© M.E. Fayad
SJSU – CmpE M.E. Fayad

48. 48 Discussion Questions T/F statements
11/28/2018
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.
Define in UML: Abstract Classes, Objects, Metaclasses, Parameterized Classes, Utility Classes, and Notes 48
© M.E. Fayad
SJSU – CmpE M.E. Fayad