Was war zuerst da: Das Abstrakte oder das Konkrete?

Das Problem, das ich in diesem Blogpost beschreibe, mutet ein bisschen wie altgriechische Philosophie an. Denn im Grunde geht es um die Frage, was zuerst kommt: Das Abstrakte oder das Konkrete?

Speziell geht es um ein Problem, dass mir bei einem aktuellen Entwicklungsprojekt aufgefallen ist, bzw. bei dessen OO-Design oder der Implementierung.

Wenn man eine Software entwickelt, beginnt man (zumindest bei einem Objekt-Orientierten Ansatz) damit, für die bestehenden Objekte aus der stofflichen Welt korrespondierende Softwareobjekte zu entwerfen.

Wenn wir davon ausgehen, dass wir in unserem System Endkunden und Vertreter haben, dann ergibt das zuerst einmal 2 konkrete Objekte (Kunde, Vertreter). Diese könnte ich mit ihren jeweiligen Attributen anlegen und loslegen. Der innere Softwareingenieur beginnt jetzt aber zu meckern und sagt mir: Kunde und Vertreter sind aber beide Personen! Folgerichtig entwerfe ich eine abstrakte Klasse Person, die gemeinsame Attribute von Kunde und Vertreter enthält.

Das Ziel ist klar: DRY (Don't Repeat Yourself) - Ich muss den gleichartigen Code nur an einer Stelle pflegen.

Für den unbeteiligten Dritten sieht es nun so aus, wie ein klares Design:

Soweit die Theorie, aber im richtigen Leben fangen die Probleme jetzt erst an:

1. Es stellt sich heraus, dass es 2 verschiedene Arten von Kunden gibt, die aber in manchen Attributen und vor allem deren Behandlung (z.B. speichern und auslesen) stark voneinander abweichen. -> Lösung eine weitere abstrakte Klasse AbstractKunde
2. Das Bankkonto, dass bisher ein einfaches Attribut der Person war, muss für Kunden und Vertreter komplett unterschiedlich behandelt werden.

Dies führt zwangsläufig zu einer etwas komplizierteren Aufteilung:

Aber da das wahre Leben noch ein bisschen gemeiner ist, stellt sich heraus, dass es zwischen dem einen Kundenkonto und dem Vertreterkonto doch einige Gemeinsamkeiten gibt...Endergebnis: Ich habe eine Vielzahl von abstrakten Klassen, die im schlimmsten Fall nur noch ein Attribut enthalten.

Die Idee das Design mit dem Abstrakten zu beginnen und hin zum Konkreten zu gehen hat sich durch ändernde Anforderungen zum Wartungalbtraum entwickelt!

In meinem nächsten Post stelle ich eine mögliche Alternative vor, die stark auf Refactoring beruht...