Garo Garabedyan- a private blog

60 Design Heuristics
Object-oriented Design Heuristics
By Arthur J. Riel

Classes and Objects: All data should be hidden within its class (Only private attributes; and Not even protected!).  Protected methods are allowed. Users of a class must be dependent on its public interface, but a class should not be dependent on its users (Somebody calls my method, and I’m dependent on the other’s behaviour or state). Minimize the number of messages in the protocol of a class (Example: SetMinimumValue(int aValue); SetMaximimumValue(int aValue);, But SetLimits(int minValue, int maxValue)). Implement a minimal public interface which all classes understand (E.g. operations such as copy (deep versus shallow), equality testing, pretty printing, parsing from a ASCII description, etc). Do not put implementation details into the public interface of a class (such as common-code private functions, in Example: Class CBill generates a reference number when the object is created, but not any other time). Do not clutter the public interface of a class with things that users of that class are not able to use or are not interested
in using (Mixture of public and private methods that must be called in a certain order; Methods with parameters, values of which are not available to other classes). Classes should only exhibit nil or export coupling with other classes ( i.e. a class should only use operations in the public interface of another class or have nothing to do with that class; No friends or at least avoid them as much as possible). A class should capture one and only one key abstraction (One simple thing, major responsibility). Keep related data and behavior in one place (Classes methods modify data that belongs to that class). Spin off non-related information into another class (i.e. non-communicating behavior). Be sure the abstraction that you model are classes and not simply the roles objects play (Objects may switch roles runtime; State may indicate role).

Topologies of Object-Oriented Applications: Distribute system intelligence horizontally as uniformly as possible (I.e. the top level classes in a design should share the work uniformly).Do not create god classes/objects in your system (Be very suspicious of an abstraction whose name contains Driver, Manager, System, or Subsystem; Does this name indicate a class that really contains too much responsibilities?). Beware of classes that have many accessor methods defined in their public interface (Many of them imply that related data and behavior are not being kept in one place; Accessor methods access other objects or too much data that is encapsulated in this class). Beware of classes which have too much  non-communicating behavior (methods which operate on a proper subset of the data members of a class; God classes often exhibit lots of noncommunicating behavior). Applications which consist of an object oriented model interacting with a user interface (the model should never be dependent on the interface; The interface should be dependent on the model). Model the real world whenever possible (This heuristic is often violated for reasons of system, intelligence distribution, avoidance of god classes, and the keeping of related data and behavior in one place). Eliminate irrelevant classes from your design and Eliminate classes that are outside the system. Do not turn an operation into a class (Be suspicious of any class whose name is a verb or derived from a verb; Especially those which have only one piece of meaningful behavior (i.e. do not count sets, gets, and prints); Ask if that piece of meaningful behavior needs to be migrated to some existing or undiscovered class). Agent classes are often placed in the analysis model of an application (During design time, many agents are found to be irrelevant and should be removed).

The Relationships Between Classes and Objects: Minimize the number of classes with which another class collaborates (The less connections the better; E.g. Facade design pattern). Minimize the number of message sends between a class and its collaborator (By defining fewer methods, for example). Minimize the amount of collaboration between a class and its collaborator (I.e. the number of different messages sent). Minimize fanout in a class (I.e. the product of the number of messages defined by the class and the messages they send). If a class contains objects of another class (then the containing class should be sending messages to the contained objects, i.e. the containment relationship should always imply a uses relationship). Most of the methods defined on a class should be using most of the data members most of the time. Classes should not contain more objects than a developer can fit in his or her short term memory (A favorite value for this number is six). Distribute system intelligence vertically down narrow and deep  containment hierarchies. When implementing semantic constraints (It is best to implement them in terms of the class definition; Often this will lead to increasing number of classes in which case the constraint must be implemented in the behavior of the class, usually, but not necessarily, in the constructor). When implementing semantic constraints in the constructor of a class (place the constraint test in the constructor as far down a containment hierarchy as the domain allows). The semantic information on which a constraint is based (is best placed in a central third -party object when that information is volatile). The semantic information on which a constraint is based (is best decentralized among the classes involved in the constraint when that information is stable). A class must know what it contains, but it should never know who contains it (Some design patterns break this rule, for example, Chain of Responsibility (used often with Composite)). Objects which share lexical scope (i.e. those contained in the same containing class; should not have uses relationships between them).

The Inheritance Relationship: Inheritance should only be used to model a specialization hierarchy. Derived classes must have knowledge of their base class by definition (but base classes should not know anything about their derived classes; State pattern). All data in a base class should be private (i.e. do not use protected data). Theoretically, inheritance hierarchies should be deep, i.e. the deeper the better; Pragmatically, inheritance hierarchies should be no deeper than an average person can keep in their short term memory (A popular value for this depth is six). All abstract classes must be base classes; All base classes should be abstract classes. Factor the commonality (of data behavior, and/or interface); as high as possible in the inheritance hierarchy. If two or more classes only share common data (no common behavior) (then that common data should be placed in a class which will be contained by each sharing class). If two or more classes have common data and behavior (i.e. methods) (then those classes should each inherit from a common base class which captures those data and methods). If two or more classes only share common interface (i.e. messages, not methods) (then they should inherit from a common base class only if they will be used polymorphically). Explicit case analysis on the type of an object is usually an error (the designer should use polymorphism in most of these cases). Explicit case analysis on the value of an attribute is often an error (The class should be decomposed into an inheritance hierarchy where each value of the attribute is transformed into a derived class). 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 semantic relationship will lead to a toggling of types at runtime). 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). 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 a class). It should be illegal for a derived class to override a base class method with a NOP method (no-operation), I.e. a method which does nothing. Do not confuse optional containment with the need for inheritance (modelling optional containment with inheritance will lead to increasing number of classes). When building an inheritance hierarchy (try to construct reusable frameworks rather than reusable components).

Multiple Inheritance: If you have an example of multiple inheritance in your design (assume you have made a mistake and prove otherwise). Whenever 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? And 2) Is the thing I’m inheriting from part of me?. Whenever you have found a multiple inheritance relationship in a objectoriented design (be sure that no base class is actually a derived class of another base class, i.e. accidental multiple inheritance).

The Association Relationship: When given a choice in an objectoriented design between a containment relationship and an association relationship, choose the containment relationship.

Class Specific Data and Behavior: Do not use global data or functions to perform bookkeeping information on the objects of a class (class variables or methods should be used instead).

Physical Object-Oriented Design: Object-oriented designers should never allow physical design criteria to corrupt their logical designs (However, very often physical design criteria is used in the decision making process at logical design time). Do not change the state of an object without going through its public interface (No public/protected data members, No friends).

Dino Esposito in May 14, 2009 have presented a lecture on Design Patterns, Refactoring and Sane Principles in Days of Microsoft’2009 in Faculty of Mathematics and Informatics, University of Sofia, Bulgaria, which I have attended.

These are my notes from the lecture:

Bad software design… deterioration in design. Bad software is hard to maintain and evolve. Complete redesign may not be an option. STOP at the first sign of deterioration.

Foundation of Software Design- Structured design (high cohesion; low coupling); and Separation of Concerns (modularity; information hiding). ClassA and ClassB are cohesive when changes to A have no repercussion on B. The problem is in the hidden dependencies, not in the public explicit (cohesion) dependencies.

Single Responsibility Principle (SRP)- give each class just one reason to change; and “Reason to change” == “responsibility”. In example: Invoice class does not have a responsibility to print itself.

Coupling: Level of dependency between 2 modules. ModuleA and ModuleB are coupled when changes to A force you to make changes on B.

Achieve stable constructed interfaces. ModuleA does not need to know internals of B.

Separation of Concerns (since 1974). Concern == feature of system. Taking care of each of the concerns: for each one concern, other concerns are irrelevant. Hiding implementation of behavior.

Object Oriented Design: 1st principle- Find pertinent object; 2nd principle- Program to an interface.

OOD is one paradigm. Nouns in requirements document are best candidates for classes, verbs- for functions (methods in classes).

Difference between inheritance and composition: inheritance enables polymorphism in parralel to composition, in general.

Advanced principles: 1) Open/Close; 2) Substitution; 3) Dependency Inversion. Open/Close- open for extension, close for modification; Substitution- subclasses should be substitutable for their base classes; Dependency Inversion- Low-level modules injected into the high-level module (not invoked by). Thus inverting the control of flow. Various patterns: dependency injection; service locator.

Dino Esposito (http://weblogs.asp.net/despos/) is Microsoft Most Valuable Professional and is one of the world’s authorities on Web technology and software architecture. He writes articles covering topics such as AJAX, Silveright, software design and patterns. The event was sponsored by Kulov.net, Musala Soft, Microsoft and Faculty of Mathematics and Inforamtics, University of Sofia, Bulgaria. The lecture was Chapter 3 of his book Microsoft® .NET: Architecting Applications for the Enterprise (PRO-Developer).

(Documentation in Bulgarian) http://unidevelop.org/wiki/project_embedded_apps_lib

(SVN Project home) http://unidevelop.org/browser/unidevelop/programming/projects/eventBasedFramework

I have wrote a small C OpenSource licensed framework implementing the ideas of eventBased Algorithms and Data and Data flow processing (http://garabedyan.wordpress.com/2008/03/04/data-flow-processing-eventbased-algorithms-and-data/) for my university exams. I have win first place best programming project in Unidevelop, Technical University- Sofia, the organizers granted me an ASUS EEE PC 4GB which event was presented in the front page of New technical avangard (official newspaper of Technical Univesity, Bulgaria) in February 2009.

The framework is aimed to handle embedded applications, but its core is universal in the context of the expressed assumptions about Object Oriented Programming (state and behaviour) eventBased Data processing (Observer pattern). Client- programmer is able to easily create variable containers and declare to them the interested functions in a change of the stored variable. Every time a variable value is changed the interested functions are informed.

Future development of the project is adding Aspect-Oriented like functionality which to enable the client- programmer to declare aspects (functions) and functions (or aspects) to be called before and after the aspect’s code is executed. Very useful to be aspects I think functions which produce outside the MCU commands.

I have used Erik Meijer: Functional Programming; MSDN Channel 9 Going Deep Show http://channel9.msdn.com/shows/Going+Deep/Erik-Meijer-Functional-Programming/ as an additional theoretical source of programming language science.

The client- programmer uses the platform as a library for calculating decision tree finding the right result in as a small period of calculation time, as possible; optimization of calculation in the program which depends on external variables (especially for those which are part of the decision tree if meet the letter condition) by in advance calculation in every change (revision) of the value of a variable.

eventBased Framework is a platform architecture aimed to advocate declarative programming in programming products handling asynchronous events.

I believe that the architecture of a program must inherit the structure of a natural science like Physics in example. There is a pure scientific explanation within the idea of of declaring and defining by such formulas in small modules source code. Programming is of its own translation (virtualization) of a real phenomena in electronic form, which is all what natural science do. The history of development (introducing new more concrete ideas and visions) of sciences goes through this process. Science tries to generalize and collect “if-then” observations describing behavior of a certain class phenomenas by transforming them into laws predicting result of a system in a moment in future. This laws have such mathematical form to enable calculation and analyze.

As far as Object Oriented Programming is an engagement of state and behavior, object oriented code can be written in languages which does not support insight mechanisms of encapsulation, powerful polymorphism with class interfaces and casting. Using methods of memory addressing with references and addressing code pieces with references to functions, engagement of state and behavior can be reached. This source code is reusable (re-editable) in a result of this OOP powerful character.

MCUs during their work handle input events. From this point of view a certain amount of variables exists, which is defined with input/ output functions important for the behavior of the system.

It is strongly recommended (close to restriction) functions called in advance to not result in hardware commands outside the MCU. Such side effects are supposed to be coordinated with the purpose of the concrete technical system.
In order achieving optimization, it is important every significant heavy calculating function to save (declare) all its input and output variables (including code side effects and dependency injection) in the global dynamic array of containers of variables (implemented by eventBased Framework) meanwhile to register its interest of all input variables in their concrete containers. When such code is called it must immediately return the execution of the program after checking if the input variables’ values have been already examined by the code.

Conclusion: Multi- stage programming and object’s oriented most significant functionality of encapsulation of state and behavior are implemented intelligently in one homogeneous software architecture unit enabling interruptions for reacting on urgent events. In parallel to reaction on every small change of some value in variable containers, the client- programmer can write functions reacting on interruptions which code on a base of small calculations of the present values in variable containers to calculate the needed reaction on the urgent situation.