l6-2-s1design heuristics - 2 © m.e. fayad 1997-2005 sjsu -- cmpe software system engineering dr....

© M.E. Fayad 1997-2005 SJSU -- CmpE L6-2-S1 Design Heuristics - 2

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

© M.E. Fayad 1997-2005 SJSU – CmpE M.E. Fayad L6-2-S2 Design Heuristics - 2

2

Lesson 6-2:Object-Oriented

Design Heuristics -2


Lesson Objectives

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!!!!


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.


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



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



7

Comparison of Macho Class & Overly Distributed Topologies

Macho Class

Overly Distributed System


A Behavior Macho Class

A Data Structure Macho Class

8

The Macho Class Problem


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 class5class1

class2 class3 class4

set_result()

get_z()

get_x()

get_y() get_q()


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 classcontrollerclass1

set_result()

get_z()

get_x()

get_y() get_q()

controllerclass2

controllerclass3

controllerclass4

controllerclass5


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


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)


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


int x;int y;

The Point Class

get_x()get_x()get_y()set_y()


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 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



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 Interfaceget/set messages

The Model-Interface Application Topology


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)


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)

data1data2data3

Func2()

Func1()

Func3()

Func4()

Func5()

Func6()

Func7()

A Legacy CallProcessing System

CallProcessingBlock


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.


20


get_data1()set_data1()get_data2()set_data2()get_data3()set_data3()

data1data2data3

CallProcessingBlock

Func2()

Func1() Func3()

Func4()

Func5()

Func6()

Func7()

ContollerClass1

ContollerClass2ContollerClass3

The CallProcessing Class

Poor Migration


21


CallProcessingBlock

Func2()

Func1() Func3()

Func4()

Func5()

Func6()

Func7()

TelephonyClass1

TelephonyClass2TelephonyClass3

A BetterMigration


22


A more difficult

But more correct solution

Solution is to break up the data structure,

encapsulating each part with its related

behavior.


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)


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



25


The Composition Entity Class

The PlayerController

P, Q, R

The PlayerApplication

The EditingController

X, Y, Z

The EditingApplication

gets/sets for the support ofP, Q, R, X, Y, Z

Reuse of Entity Classes Via Controller Classes


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


The Composition Entity Class

The PlayerApplication

The EditingApplication

Only uses P, Q, and R Only uses X, Y, and Z

P, Q, R, X, Y, ZA Better Design for

The Composition Class


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



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)


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)


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)


31


VacationDental Plan

Car

SalarySicktime Medical Plan

inheritance

Full Employee

benefits()

compute_taxes()benefits()

New Employee


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



We could transform the design such that it obeys the “Always inherit from an abstract class” heuristic.

33


VacationDental Plan

Car

SalarySicktime

Medical Plan

Orientation

New Employee Full Employee

compute_taxes()benefits()

benefits()

inheritance


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



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



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



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



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



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



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



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



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



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



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



45


Security

FuturesStocksBonds

Tax-Free Zero-Coupon Lotus IBM Gold Oil

etc etc etc


46


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 LotusGold

Gold Zero Lotus


47


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


• 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

l6-2-s1design heuristics - 2 © m.e. fayad 1997-2005 sjsu -- cmpe software system engineering dr....

Documents