This is what Jim Weirich tried to present in 2009, I know this was 3 years old, but it’s so important to ignore it.
Basically what Jim proposed is a concept that contains software engineering practices, such as:
- SOLID
- Law of Demeter
- DRY
- Small Methods
- Design by Contract
This Unified Theory is called Connascence and derives from “What Every Programmer SHOULD KNOW ABOUT OBJECT ORIENTED DESIGN” by Meilir Page-Jones, in words of Jim Weirich
… however the third part of the book is worth the price of the entire book, and in that part he defines a term called Connascence …
What this concept tries to cover is the knowledge of some element based on the existence of a different element created (born) at the same time.
So we have several categories of Connascence:
- Name: when multiple components must agree on the name of the entity
- Type: when multiple components must agree on the type of an entity
- Meaning: when multiple components must agree on the meaning of specific values
- Position: when multiple components mus agree on the order of values
- Algorithm: when multiple components must agree on a particular agreement
- Execution: when the order of execution of multiple components is important
- Identity: when multiple components must reference the entity
Ok, I’m not going to enter in details, in fact my advise is view the presentation by Jim Weirich and check Gregory Brown’s article Connascence as a Software Design Metric, which is the one that introduce me into this concept.
All I want to write here is the understanding I have for this concept, so if any of you disagree or have better ways to explain, please comment :)
Connascence exists when the coupling between two or more entities demands a change in those entities (method name, parameters, execution, etc.) if one of the entities change its coupled property