Object-Oriented DesignHeuristics

Harald Gall, Prof. Dr.http://seal.ifi.unizh.ch

2

Design Heuristics

Object-Oriented Design Heuristics byArthur Riel, Addison-Wesley, 1996.

3

Goal

Insights into oo design improvement.

More than sixty guidelines are language-independent and allow one to rate theintegrity of a software design.

The heuristics are not written as hard andfast rules; they are meant to serve aswarning mechanisms which allow theflexibility of ignoring the heuristic asnecessary.

Classes and Objects

The Building Blocks of the Object-Oriented Paradigm

5

Hidding Data

Heuristic #2.1All data should be hidden within its class

6

No Dependence on Clients

Heuristic #2.2Users of a class must be dependent on itspublic interface, but a class should not bedependent on its users

7

Support Class = 1 Clear Responsibility

Heuristic #2.3Minimize the number of messages in theprotocol of a class

8

Supporting Polymorphism andCommunication

Heuristic #2.4Implement a minimal public interface which allclasses understand (e.g. operations such ascopy (deep versus shallow), equality testing,pretty printing, parsing from a ASCII description,etc.).

To send the same message to different objects To be able to substitute them

Example: Object>>printString, Object>>copy…

9

Clear Public Interface

Heuristic #2.5Do not put implementations details such ascommon-code private functions into the publicinterface of a class

Example: Private/protected in C++ Private method categories in Smalltalk

Do not clutter the public interface of a class withitems that clients are not able to use or are notinterested in using

10

Minimize Classes Interdependencies

Heuristic #2.7A class should only use operations in thepublic interface of another class or havenothing to do with that class

11

Support a Class = one Responsibility

Heuristic #2.8A class should capture one and only onekey abstraction

12

Strengthen Encapsulation

Heuristic #2.9Keep related data and behavior in oneplace

Spin off non related information intoanother class

-> Move Data Close to Behavior

13

Object: a Cohesive Entity

Most of the methods defined on a classshould be using most of the instancevariables most of the time

14

Roles vs. Classes

Heuristic #2.11Be sure the abstractions you model areclasses and not the roles objects play

Are mother and father classes or role ofPerson?

No magic answer: Depends on the domain Do they have different behavior? So they

are more distinct classes

Topologies of Action-Orientedvs. Object-Oriented Applications

16

Support 1 Class = 1 Responsibility

Heuristic #3.1Distribute system intelligence horizontallyas uniformly as possible, i.e., the top-levelclasses in a design should share the work

17

Support 1 Class = 1 Responsibility

Heuristic #3.2Do not create god classes/objects (classesthat control all other classes). Be verysuspicious of classes whose namecontains Driver, Manager, System,SubSystem

18

Model and Interfaces

Heuristic #3.5Model should never be dependent on theinterface that represents it. The interfaceshould be dependent on the model

What is happening if you want twodifferent UIs for the same model?

19

Basic Checks for God Class Detection

Heuristic #3.3Beware of classes that have many accessormethods defined in their public interface. Mayimply that data and behavior is not being kept atthe same place

Heuristic #3.4Beware of classes having methods that onlyoperate on a proper subset of the instancevariables.

20

One Class: One Responsibility

One responsibility: coordinating and usingother objects OrderedCollection maintains a list of objects

sorted by arrival order: two indexes and a list

Class should not contain more objectsthan a developer can fit in his short-termmemory. (6 or 7 is the average value)

21

Classes Evaluation

Model the real world whenever possible

Eliminate irrelevant classes

Eliminate classes that are outside of the system

A method is not a class. Be suspicious of anyclass whose name is a verb or derived from averb, especially those that only one piece ofmeaningful behavior

The Relationships BetweenClasses and Objects

23

Minimizing Coupling between Classes

Minimize the number of classes with whichanother class collaborates

Minimize the number of messages sentbetween a class and its collaborators Counter example: Visitor pattern

Minimize the number of differentmessages sent between a class and itscollaborators

24

About the Use Relationship

When an object use another one it should get areference on it to interact with it

Ways to get references (containment) instance variables of the class Passed has argument Ask to a third party object (mapping…) Create the object and interact with it (coded in class:

kind of DNA)

25

Containment and Uses

Heuristic #4.5If a class contains object of another class, thenthe containing class should be sendingmessages to the contained objects (thecontainment relationship should always imply auses relationships)

A object may know what it contains but it shouldnot know who contains it.

26

Coherence in Classes

Heuristic #4.6Most of the methods defined on a class shouldbe using most of the data members most of thetime.

Heuristic #4.7Classes should not contain more objects than adeveloper can fit in his or her short termmemory. A favorite value for this number is six.

Heuristic #4.8Distribute system intelligence vertically downnarrow and deep containment hierarchies.

27

Representing Semantics Constraints

How do we represent possibilities or constraintsbetween classes? Appetizer, entrée, main dish… No peas and corn together…

It is best to implement them in terms of classdefinition but this may lead to class proliferation

=> implemented in the creation method

28

Objects define their logic

Heuristic #4.9When implementing semantic constraintsin the constructor of a class, place theconstraint definition as far down acontainment hierarchy as the domainallows

=> Objects should contain the semanticconstraints about themselves

29

Third party constraint holder

Heuristic #4.11The semantic information on which a constraintis based is best placed in a central third-partyobject when that information is volatile.

Heuristic #4.12The semantic information on which a constraintis based is best decentralized among theclasses involved in the constraint when thatinformation is stable.

The Inheritance Relationship

31

Classes - Subclasses

Superclass should not know its subclasses

Subclasses should not use directly data ofsuperclasses

If two or more classes have common data andbehavior, they should inherit from a commonclass that captures those data and behavior

32

Inheritancs for Specialization

Heuristic #5.1Inheritance should only be used to model aspecialization hierarchy.

Vererbung ist ein White-box-Entwurf Aggregation oder Komposition definieren einen

Black-box-Entwurf Richtiger Einsatz von Vererbung erleichtert das

Programmverständnis enorm!

33

Base Class Knowledge

Heuristic #5.2Derived classes must have knowledge oftheir base class by definition, but baseclasses should not know anything abouttheir derived classes.

34

Base Class Data is Private

Heuristic #5.3 All data in a base class should be private,

i.e. do not use protected data.

35

Inheritance Depth

Heuristic #5.4Theoretically, inheritance hierarchies should bedeep, i.e. the deeper the better.

Heuristic #5.5Pragmatically, inheritance hierarchies should beno deeper than an average person can keep intheir short term memory. A popular value forthis depth is six.

36

Controversial

All abstract classes must be base classes

All base classes should be abstractclasses > Not true they can have default value method

37

Interfaces

Heuristic #5.8Factor the commonality of data, behavior,and/or interface as high as possible in theinheritance hierarchy.

Heuristic #5.10If two or more classes have common data andbehavior (i.e. methods) then those classesshould each inherit from a common base classwhich captures those data and methods.

38

Inheritance (2)

Heuristic #5.9If two or more classes only share common data(no common behavior) then that common datashould be placed in a class which will becontained by each sharing class.

Heuristic #5.11If two or more classes only share commoninterface (i.e. messages, not methods) thenthey should inherit from a common base classonly if they will be used polymorphically.

39

Avoid Type Checks

Explicit case analysis on the type of an objects isusually an error.

An object is responsible of deciding how toanswer to a message

A client should send message and notdiscriminate messages sent based on receivertype

40

Dynamic semantics

Heuristic #5.14Do not model the dynamic semantics of a classthrough the use of the inheritance relationship.An attempt to model dynamic semantics with astatic semantic relationship will lead to a togglingof types at runtime.

Heuristic #5.15Do not turn objects of a class into derivedclasses of the class. Be very suspicious of anyderived class for which there is only oneinstance.

Multiple Inheritance

42

Prove Multiple Inheritance

Heuristic #6.1If you have an example of multipleinheritance in your design, assume youhave made a mistake and proveotherwise.

43

Question it

Heuristic #6.2Whenever there is inheritance in an object-oriented design ask yourself two questions: 1) Am I a special type of the thing I'm inheriting from? 2) Is the thing I'm inheriting from part of me?

Heuristic #6.3Whenever you have found a multiple inheritancerelationship in a object-oriented design be surethat no base class is actually a derived class ofanother base class, i.e. accidental multipleinheritance.

The Association Relationship

45

Containment

Heuristic #7.1When given a choice in an object-orienteddesign between a containmentrelationship and an associationrelationship,choose the containment relationship.

Class Specific Data andBehavior

47

Use of Class Variables & Methods

Heuristic #8.1Do not use global data or functions toperform bookkeeping information on theobjects of a class, class variables ormethods should be used instead.

48

Summary

Use the guidelines for insightful analysis critical reviews as guide for better oo design to build reusable components and

frameworks