Streit zwischen YAGNI und Open Closed Principle

Kürzlich hatte ich ein interessantes Gespräch darüber, ob man durch die Einhaltung von OCP YAGNI über den Haufen wirft. Hintergrund war der, dass ich persönlich meine Kontrakte (Interfaces) immer in eine separate Assembly lege. Wenn die Implementierung beispielsweise in “MyProgram.Finances” liegt, dann gibt es eine “MyProgram.Finances.Contracts”, die alle in “MyProgram.Finances” verwendeten Interfaces enthält. Das ist meine persönliche Konvention für meine Programme. Aus meiner Sicht entspricht dies perfekt dem OCP, da auf diese Art jeder Entwickler in der Lage ist anhand der Contracts seine eigene Implementierung zu schreiben und diese im IoC Container über einen Installer zu registrieren. Er muss dann lediglich meine Implementierung löschen. Generell macht das ganze Vorgehen besonders bei einer IoC Architektur Sinn!

Die andere Sichtweise war nun: Warum Overengineering betreiben, wenn es sowieso nur eine Implementierung gibt und wir rein für uns entwickeln, sprich es keine Dritte gibt, die separate Lösungen anbieten wollen? Das widerspräche dem YAGNI Prinzip. Der Gegenvorschlag war also, dass alles in die gleiche Assembly kommt. Das Interface wäre immer noch Public und die Implementierung internal, da man ja weiterhin die Implementierung im IoC registriert.

Das Problem ist in dem Fall, dass man eben nicht mehr die Freiheit hat die Implementierung zu überschreiben ohne den bestehenden Code anzufassen.

Persönlich sehe ich es nicht so, dass man gegen das YAGNI Prinzip verstößt, wenn man die Interfaces in eine separate Assembly legt, da man nicht “mehr” Code entwickelt, sondern lediglich die Architektur von Anfang an offen bzw. erweiterbar hält. Natürlich hat man jetzt ein Projekt mehr, aber der eigentliche produktive Code ist der gleiche. Hingegen verstößt man imho definitiv gegen das OCP, wenn man man die Interfaces nicht separiert.

Wie seht ihr das? Feedback über Facebook, Twitter oder WordPress ausdrücklich erwünscht!

Mit Tag(s) versehen:

5 thoughts on “Streit zwischen YAGNI und Open Closed Principle

  1. bfreakout 6. März 2012 um 1:17 Reply

    Hallo Uli,

    normal werden nur die Methoden umgesetzt die für die funktionale Anforderungen relevant sind. Dann bestückt man alle restlichen Methoden mit einer Exception (z.B. NotImplementedException). Sollte es dann beim Testen krachen, wird sofort ersichtlich welche Methoden enorm wichtig sind. Methoden die keine relevante Rolle haben, bleiben dann frei von Logik. Man geht nämlich davon aus, das beim laden von bestimmten Komponenten auch nicht alle Funktionen eines anderen contrakts in anspruch genommen werden.

    Somit kannst du perfekt das OCP einhalten und betreibst nicht zu viel Aufwand für die zusätzliche implementieren von unnötigen Code (YAGNI).

    Viele Grüße,
    Gregor

    Gefällt mir

  2. Mario Priebe 16. März 2012 um 9:10 Reply

    Hallo Uli,

    => Wenn die Implementierung beispielsweise in “MyProgram.Finances” liegt, dann gibt es eine “MyProgram.Finances.Contracts”, die alle in “MyProgram.Finances” verwendeten Interfaces enthält. Das ist meine persönliche Konvention für meine Programme. <=

    wie machst du das, wenn du in einem Interface einen Typen definieren möchtest, dieser sich aber dort befindet, wo du auch deine Interfaces implementierst?

    Gefällt mir

    • Uli Armbruster 16. März 2012 um 14:04 Reply

      Hey Mario,
      was meinst du mit Typen? DTOs landen ebenfalls in der Contracts Assembly, da sie ja Datenkontrakte sind. Entitäten aus dem OR-Mapper sind ebenfalls in einer separaten Assembly. Welche Typen bleiben dann noch übrig?

      Gefällt mir

      • Mario Priebe 16. März 2012 um 14:48 Reply

        okay, das ist dann plausibel. Ich dachte du trennst Contracts von den DTOs.

        Gefällt mir

  3. […] ich ebenfalls zu den Kontrakten zähle (vergleicht dazu diesen Artikel), ist das DTO MyHecoUser, welches später die gefüllten Daten zum Austausch innerhalb von PHP […]

    Gefällt mir

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

%d Bloggern gefällt das: