Die Definition von schlechtem Design

The most common criterion that I have seen used is the TNTWIWHDI or “That’s not the way I would have done it” criterion.

But there is one set of criteria that I think all engineers will agree with. A piece of software that fulfills its requirements and yet exhibits any or all of the following three traits has a bad design.

  1. It is hard to change because every change affects too many other parts of the system.
    (Rigidity)
  2. When you make a change, unexpected parts of the system break.
    (Fragility)
  3. It is hard to reuse in another application because it cannot be disentangled from the current application.
    (Immobility)

Moreover, it would be difficult to demonstrate that a piece of software that exhibits none of those traits, i.e. it is flexible, robust, and reusable, and that also fulfills all its requirements, has a bad design. Thus, we can use these three traits as a way to unambiguously decide if a design is “good” or “bad”.

Quelle: Robert C. Martin, http://www.objectmentor.com/resources/articles/dip.pdf

Verwandte Artikel:

Wissen ist Macht! Zu viel Wissen schadet.

In einem klassisch aufgebauten OO-System ist jedes Objekt selbst dafür zuständig, seine Abhängigkeiten, also benötigte Objekte und Ressourcen, zu erzeugen und zu verwalten. Dafür muss jedes Objekt einige Kenntnisse seiner Umgebung mitbringen, die es zur Erfüllung seiner eigentlichen Aufgabe normalerweise nicht benötigen würde. Insbesondere muss es, um die entsprechenden Objekte erzeugen zu können, ihre konkrete Implementierung kennen.

Ein Implementierungsbeispiel mit dem ASP.NET MVC Framework, dem DI Framework StructureMap 2.0 in C# und etwas TDD:

http://haacked.com/archive/2007/12/07/tdd-and-dependency-injection-with-asp.net-mvc.aspx

Mehr: http://de.wikipedia.org/wiki/Dependency_Injection

Verwandte Artikel: