Maxim Hierarchy

This is an attempt to categorise maxims.

Design & Implementation

All those maxims related to the system itself.

Separate and group system parts rationally

Defining the objects

• Encapsulation boundary
• Model the real world
• Behavioral completeness
• Single responsibility principle
• Separation of concerns
• One responsibility rule

Object Behaviour

• Avoid downcasting
• Avoid equals

Object Interface

• Encapsulate that which varies
• Encapsulation is hierarchical
• Once and only once
• Dependency inversion principle
• Interface segregation principle
• Fat interfaces
• Hide your decisions
• Information hiding
• Tell, Don't Ask
• Program to the interface not the implementation

Inheritance

• Favor composition over inheritance
• Avoid inheritance for implementation
• Don't burn your base class
• Law of leaky abstractions
• Liskov substitution principle
• No concrete base classes
• Stable abstractions principle
• Open closed principle - ?
• Design by contract

Object Mutability

• Don't expose mutable attributes
• Getters and setters
• Keep accessors and mutators separate
• Command query separation
• Avoid side effects

Avoid unnecessary complexity

Reuse

• Common reuse principle
• Software reuse
• Once and only once
• Don't repeat yourself
• Reuse release equivalence principle

Do only what is necessary

• Do the simplest thing that could possibly work
• You ain't gonna need it
• Premature optimization
• Keep it simple
• Establishing priorities

Readable Code is Good Code

• Named constants
• Goto considered harmful

Group Stuff To Reduce Complexity

• Common closure principle
• Single choice principle

Dependencies

• Dependency injection
• Stable dependencies principle
• Acyclic dependencies principle
• Coupling and cohesion
• Impedance mismatch
• Law of Demeter

Process & Organisation

All the maxims related to the development processes and management of the development team.

OO Developers are not perfect

• Big design up front
• Software crisis
• No silver bullet