Revision as of 00:35, 1 October 2010 (view source) Lukas Korsika (Talk | contribs) (→Defining the objects: One responsibility rule just redirected to Single responsibility principle anyway. No need to have them twice.) ← Older edit	Latest revision as of 03:08, 25 November 2010 (view source) WikiSysop (Talk | contribs) m (Reverted edits by Ebybymic (Talk); changed back to last version by Lukas Korsika)
(One intermediate revision by one user not shown)

---

Latest revision as of 03:08, 25 November 2010

This is an attempt to categorise maxims.

Contents 1 Design & Implementation 1.1 Separate and group system parts rationally 1.1.1 Defining the objects 1.1.2 Object Behaviour 1.1.3 Object Interface 1.1.4 Inheritance 1.1.5 Object Mutability 1.2 Avoid unnecessary complexity 1.2.1 Reuse 1.2.2 Do only what is necessary 1.2.3 Readable Code is Good Code 1.2.4 Group Stuff To Reduce Complexity 1.3 Dependencies 2 Process & Organisation 2.1 OO Developers are not perfect

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

Object Behaviour

• Avoid downcasting
• Avoid equals

Object Interface

• Encapsulate that which varies
• Encapsulation is hierarchical
• Option-operand separation
• 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