Das höchste Ziel in der Physik ist alle Kräfte durch eine Formel auszudrücken bzw. sie in Beziehung zueinander zu setzen. Maxwell zum Beispiel gelang das für elektrische und magnetische Felder - und dafür ist er noch heute berühmt.

In der Software-Entwicklung gibt es so etwas bisher nicht. Klar, es gibt Daumenregeln, so wie:

• Keep it DRY
• Keep your Methods Small **
• Work SOLID
• Obay the Law of Demeter
• und so weiter…

Aber, und das ist der wichtige Teil: diese Daumenregeln sind keine Unifikation die die verschiedenen Probleme beim Programmieren abwägen und in Beziehung setzen.

Daher finde ich Jim Weirichs Vortrag The Building Blocks of Modularity sehr spannend - denn da stellt er den Ansatz der Connascence vor (ab Folie 35).

Das ist letztlich eine Klassifizierung welche Art von Abhängigkeit man sich durch welche Programmiertechnik einfängt - und damit kann man 'normales' Refactoring anwenden um von problematischeren Connascence's (?) zu weniger problematischen zu kommen.

Ach ja, ursprünglich kommt das aus dem Buch What every Programmer should know about Object Oriented Design. Davon kann man aber Getrost nur noch den dritten Teil lesen (über Connascence) - der rest ist nach 15 Jahren einfach veraltet. :)

** Niemand sagt das so gut wie Kent Beck: "Lots of little pieces - Good code invariably has small methods and small objects. Only by factoring the system into many small pieces of state and function can you hope to satisfy the “once and only once” rule. I get lots of resistance to this idea, especially from experienced developers, but no one thing I do to systems provides as much help as breaking it into more pieces."