Clean Code Series – Episode 1

Hier der Blogeintrag zu dem entsprechenden Video. Es geht um ein Frage eines Bekannten, der SAP Lösungen entwickelt und der von mir Vorschläge für einen Ansatz einer Problemdomäne aus seiner Praxis haben wollte.

Hier die Modalitäten:

Ausgangssituation:

· Wir haben eine Entität, beispielsweise eine Liste von Aktivitäten

· Diese Entität filtert abhängig vom angemeldeten User einige Aktivitäten und liefert den Rest an den Aufrufer zurück

· Der Filtermechanismus und die eigentliche Liste sind auf zwei Klassen aufgeteilt, die beide dasselbe Interface implementieren

· Beide Klassen hängen nur in Form einer Aufrufhierarchie voneinander ab und sind in Reihe geschaltet (Decorator)

· Der Filtermechanismus hat Abhängigkeiten zu einer Datenbankzugriffsklasse

Das schreit ja förmlich nach IoC: Zusammenbauen einer Aufrufhierarchie über Decorator, dazu ggf. weitere Abhängigkeiten auflösen.

Schön. Aber leider ist es eine schlechte Idee, konkrete Entitäten über einen IoC Container zu erzeugen.

Was also tun? Factories bauen?

Ich denke nicht, wäre es nicht geschickter, auf die Klassen das Prototype-Pattern anzuwenden?

Der IoC erzeugt dann lediglich einen Prototypen, der von den Erzeugern konkreter Arbeitslisten als Vorlage genutzt würde. Instanziierung dann folglich über prototype->clone( ).

Was denkst du?

Meine Antwort:

Für mich ist der Ansatz nicht gut modelliert. Könnt ihr das nicht in einer Klasse abbilden? Aus Sicht des Domain Driven Designs könnte man das vielleicht so implementieren:

Ihr habt eine Klasse Activities, welcher ihr beim Erzeugen die Liste alle möglichen Activities übergeben müsst. Im Konstruktor könnt ihr nach Belieben noch eine Validierung vornehmen, z.B. ob die Liste überhaupt Elemente enthält bzw. nicht null ist.

Die Gesamtmenge speichert ihr in einer privaten Variablen. Zusätzlich legt ihr ein readonly Feld für den Zugriff von außen an. Danach benötigt die Klasse nur noch Filtermöglichkeiten. In .NET würde man nur eine Methode schreiben, nämlich ApplyFilter und übergibt an diese einen Lambda Ausdruck. […] Übrigens: Wie du intern die Datenhaltung betreibst, ist dir überlassen. Ich habe es beispielsweise mit einer Liste gemacht, die wesentlich spezieller ist als Enumerable. Da könntest du sogar den Spaß in eine Textdatei wegspeichern und bei Aufruf immer wieder auslesen. Hier ist die klare Datenkapselung eingehalten. Nach außen hin sieht man eine Veröffentlichung auf Basis der sehr generischen IEnumerable Implementierung, intern verwende ich etwas sehr Spezielles.

Nach kurzer Diskussion, was ABAP hier an Möglichkeiten bietet, habe ich folgenden Vorschlag gemacht:

Clean Code Series–Episode 1

Was meint ihr?

Mit Tag(s) versehen: , ,

5 thoughts on “Clean Code Series – Episode 1

  1. Dennis Traub (@DTraub) 11. November 2012 um 11:04 Reply

    Man könnte es alternativ auch als Spezification implementieren. Darin kann man bei Bedarf auch komplexe Filtermechanismen abbilden, die über eine reine Property-Abfrage hinausgehen und z.B. Drittinformationen benötigen.

    Code: https://gist.github.com/4054334

    Specification Pattern: http://en.wikipedia.org/wiki/Specification_pattern

    Gefällt mir

  2. Uli Armbruster 11. November 2012 um 13:27 Reply

    An die Möglichkeit mit Lambda-Ausdrücken hatte ich auch gedacht, aber das gibt ABAP nicht her.

    @Uwe: Die Lösung von Dennis finde ich eleganter. Denkst du, dass du das mit ABAP so ähnlich abgebildet kriegst?

    Gefällt mir

  3. Uwe Kunath 11. November 2012 um 15:37 Reply

    Definitiv, diese Variante wäre weit flexibler. Wie in Wikipedia erwähnt, lässt sich die Logik relativ leicht kombinieren und erlaubt dadurch auch Komposite. Das erste C#-Beispiel lässt sich mit den ABAP-Sprachmitteln auch 1:1 umsetzen. Finde ich perfekt gelöst!

    Gefällt mir

  4. Anonymous 18. Januar 2013 um 13:03 Reply
  5. Uli Armbruster 18. Januar 2013 um 17:46 Reply

    Vielleicht noch einen erklärenden Text dazu?

    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: