Design Rules Catalog

 This catalogue unifies, completes, and formats under the term “Rule”: Principles, Bad Smells, Best Practices, and so on. These rules are applicable to Object Oriented (OO) Micro Architectural Design, according to the OO design knowledge ontology (see in spanish).

For the description of a rule, the catalog takes as a base the sections which (Gamma, Helm, Johnson, & Vlissides, 1995) use to describe a pattern, generalizing and detailing these sections.

The relationships of rules with patterns and refactorings come under the following categories:

  • Implies the use of [Patterns]: Patterns that are necessary in a design resulting from the application of a rule. These patterns solve design problems of the new micro architecture.
  • Is introduced by [Refactorings]: Refactorings or operations, which place the rule on the micro architecture.

On the other hand, another important issue is that each rule is identified by a meaningful name. We have been careful in the choice of these names, in order to help the designer to identify speedily where and when a rule is violated. So, we have avoided names which may be attention-catching but which are not very meaningful (as happens, for instance with bad smells (Fowler, Beck, Brant, Opdyke, & Roberts, 2000) with names such as Lazy Class or Shotgun Surgery. Therefore, the rules are named according to their antecedent.

  • If there is any software design element (class, methods, code, and so on) duplicate then eliminate the duplication.
  • If there are dependencies on concrete classes then these dependencies should be on abstractions (see in English).
  • If an object has different behaviour according to its internal state then places each one of these behaviours in a separate class (see in English).
  • If a hierarchy of classes has too many levels then reduce the level of inheritance using composition or redesign
  • If there are unused or little used items then eliminate it
  • If a super class knows any of its subclasses then eliminate it.
  • If a class collaborates with too many others then reduce the number of collaborations.
  • If a change in an interface has an impact on many clients then create specific interfaces for each client.
  • If there is not an abstract class between an interface and its implementation then create an abstract class with an implementation by default between the interface and the class that implements it.
  • If a service has many parameters then create various methods, reducing the list or put these into an object.
  • If a class is too large then reduce its size by sharing out functionality over other classes.
  • If any element of the user interface is in domain entities then place these elements in a separate entity.
  • If a class rejects something that it inherited then avoid it, generally for delegation.
  • If the attributes of a class are public or protected then make them private and access to them through services.