This page and all linked pages about the subject are a work-in-progress
There are some principles in object orientation which can be followed.
What I've seen among programmers and architects is that we talk too often about design patterns, disregarding the underlying principles.
In reality, when implementing design patterns, one should also follow the underlying principles.
Thus, these principles are positioned in terms of importance before design patterns.
Some of the following items are not principles by themselves, but the core of object orientation. I will pull them into the discussion because I've seen them often being violated or not correctly used (in the languages in which they're available in some way).
Some other items are not principles to follow, but “anti-principles”. I also pull them into consideration, to put things in perspective.
Furthermore, some of the concepts listed below are neither of the above, just various metrics or ideas which do play an important role when developing an understanding for the other terms.
And finally, one cannot respect all principles, some of them being in conflict with each other by definition.
The purpose of these articles is to highlight some observations and to collect some advice, so that more sensible compromises can be struck when designing systems.
- the “a vs b” series and code measurements
- dependencies have to be clear; do not have hidden dependencies
- put the object in a valid state during initialization (constructor), and if not possible, throw an exception
- decompose the architecture in a tree-like structure, with big components at the top, hiding away details
- pass dependencies in this tree-like architecture from top to bottom, decomposing them into more granular part at each level; components should interact only with their immediate neighbors in this architectural tree
- isolate object creation (usage of
new) in factories
- make sure that the public API (public and protected non-final methods and properties) does not allow an object to get corrupted; this is done by not violating preconditions and invariants
new, and conversely, do not use