Skip to content

Object-Oriented Design and Programming Guidelines

Applies to all projects in OOP languages (C++, Java).

Class Design

  • Explicitly mark methods that implement or override a supertype definition (override in C++, @Override in Java).
  • Prefer composition over inheritance; keep hierarchies shallow.
  • Leaf classes must not be extensible (final in Java, final in C++); non-leaf classes must be abstract.
  • Never instantiate non-leaf classes directly.
  • One primary responsibility per class — one reason to change.

SOLID Principles

  • S — Single Responsibility: a class has exactly one reason to change.
  • O — Open/Closed: open for extension, closed for modification — add behaviour without touching existing code.
  • L — Liskov Substitution: a subtype must honour every contract of its supertype; callers must not need to know the concrete type.
  • I — Interface Segregation: prefer narrow, focused interfaces over monolithic ones; callers depend only on the methods they use.
  • D — Dependency Inversion: depend on abstractions, not concretions; inject dependencies rather than constructing them internally.

Design Patterns

  • Apply GoF patterns where they solve a proven, recurring design problem — name the pattern in a code comment or doc comment.
  • Prefer patterns that reduce coupling: Strategy, Observer, Decorator, Factory Method, Abstract Factory.
  • A simple class with a clear name beats a contrived pattern applied for its own sake.
  • Document pattern intent: state which pattern is applied and why, not how it works.

Coupling and Cohesion

  • High cohesion within a class; low coupling between classes.
  • Law of Demeter: talk to direct collaborators only — avoid chaining through intermediary objects (a.getB().getC().doX() is a smell).
  • Tell, don't ask: send commands to objects rather than interrogating their state to make decisions on their behalf.

References

  • Design Patterns: Elements of Reusable Object-Oriented Software — Gamma, Helm, Johnson, Vlissides, 1994 (GoF)
  • Effective Java — Joshua Bloch, 3rd ed., 2018
  • Clean Code — Robert C. Martin, 2008
  • Object-Oriented Software Construction — Bertrand Meyer, 2nd ed., 1997
  • A Behavioral Notion of Subtyping — Liskov & Wing, ACM TOPLAS 16(6), 1994 (formal LSP foundation)
  • Design Principles and Design Patterns — Robert C. Martin, 2000 (origin of the SOLID acronym)