Object Oriented Design Heuristics

• Object Oriented Design Heuristics is a concept within Software Reengineering.

Interfaces and Abstract Classes

• Used to define key components in a system.
• Interfaces declare intent by defining functions implemented by classes.
• Abstract classes declare intent and incorporate implementations for some methods.
• Abstract classes serve as extension points, which is particularly useful in software frameworks.
• With Encapsulation/Information hiding, function and data members can be public, protected, or private.

Inheritance

• Allows a class to inherit functions and data members from another class.
• Elements inherited should only be public or protected.
• Inheritance is key to using abstract classes.
• Overriding occurs when a sub-class re-defines a method declared in a superclass.
• Overriding supports understandability as it signals an "is-a" relationship between components.
• Inheritance supports code reuse.

Good Design

• Architectures erode due to bad design decisions, often made when the system is unclear.
• Good design ensures system architecture is easy to understand via:
  • Judicious use of design constructs.
  • Decomposing the system into clear and obvious modules.
• Good design makes architectures more robust and sustainable by making it harder to make bad decisions.

Relating Domain Concepts to Code

• Related data and behavior should reside in the same place.
• Classes should be entirely understandable via domain concepts and self-contained by not relying on other classes.
• Classes should have a single responsibility and should not be too large.
• "Separation of Concerns" means that code areas of responsibility should be straightforward to identify.

Modularity

• A module serves as a design construct that facilitates system understanding, typically classes in an OO system.
• Software should be understandable in terms of modules without excessive dependence.
• Modules should be easily replaceable, reusable, extendable, and adaptable.
• Modularity can be conceptualized by:
  • Coupling: Degree of interaction across module boundaries.
  • Cohesion: Degree of interaction within modules.

Law of Demeter

• Design heuristic encouraging loose coupling and high cohesion.
• Also known as “Don't talk to strangers”.
• Method M in Object O may only invoke methods in the following objects:
  • O itself.
  • M's parameters.
  • Any objects created/instantiated within M.
  • O's direct component objects.
• Avoid calling methods on objects returned by another method and "lots of dots" call-chains, such as x.y().z()...

SOLID Object Oriented Design Principles

• Single Responsibility Principle (SRP): Classes and methods should have a single responsibility.
• Open-Closed Principle: Objects should be open for extension, but closed for modification without sourcing the code.
• Liskov Substitution Principle: Objects should be replaceable with instances of their subtypes without affecting program correctness.
• Interface Segregation Principle: Many client-specific interfaces are better than a general-purpose interface; code should not depend on interfaces with unused methods.
• Dependency Inversion Principle: Code should depend upon abstractions, not concretions.

Summary

• High Level Heuristics includes a clear relationship between problem domain and software modules and modular design that has loose coupling and high cohesion.
• Interfaces and abstract classes convey design intent and highlight key components.
• Visibility of data and functions can be controlled to reduce complexity and avoid misuse.
• Inheritance enables code-reuse and extensibility while signaling domain relationships between classes.