Wednesday, October 15, 2008

Good OOD Axioms

Every application written in an object oriented programming language has a design.

No design is design, procedural code in one God Class and a myriad of Data Classes is design, the list can grow and grow.

The above mentioned application contains a number of objects (enforced by the language) that collaborate to produce the application's outcome(s). Reverse engineer any application and you will be able to visualize a form of design.

Object Oriented Design from methodology to exact science

OOD has evolved in the last decade from simple methodology and heuristics towards exact science: the science of building good object oriented designs!

Vague expressions like "thinking in terms of objects", "responsibilities & collaborations",
were gradually replaced by more structured approaches:
  • Good and Poor designs in terms of implementation and maintenance costs
  • well structured books & trainings
  • principles and laws
  • patterns
  • tools that can aid a design process
I'm not only discussing waterfallish design, but also agile design.

Axioms

Time & practice lead to well structured information about Good Designs.
Similar to an exact science, OOD should now define it's axiomatic roots!

Sets of statements like:
  1. My design goal is to minimize my future work.
vs.

1. I must minimize coupling.
2. I must grow cohesion.

vs.
I must respect:
1. Open Closed
2. Interface Segregation
3. Liskov Substitution
4. Low of Demeter

may share the same goal, may become in OOD what parallel axiomatic systems represent in modern mathematics and physics.

Different opinions? ;)

No comments: