Echte Komponentenorientierung bedeutet mehr als einfach ein Interface für eine Klassenimplementierung zu haben.
Angenommen Ihre Komponentenklassen implementieren alle ein Interface. Dann haben Sie einen Kontrakt der die Schnittstelle der Komponente klar definiert. Gut, dass ist schon viel, vielleicht mehr als einige Software bisher je hatten. Nur wenn diese Schnittstelle dann in der selben Assembly wie die Implementation liegt, dann haben Sie noch nicht viel gewonnen.
Skalierbar sind Sie damit nicht. Und auch nicht wirklich flexibel. Was wenn Sie nur die Implementierung austauschen möchten, einem Freelancer nur einen Teil des Projekts zugänglich machen wollen oder die Kontrakte unabhängig von der Implementation zentral erstellen wollen?
Vielleicht kann man für diese Probleme sogar noch irgendwie eine umständliche Lösung finden. Die Praxis hat mir aber gezeigt, dass die richtige Komponentenorientierung, wie Ralf Westphal sie schon einige Zeit im Zusammenhang mit der Systemorientierten Programmierung (SOP) predigt, ganz andere Stärken hat.
The power of real component oriented architecture I - Verträge nur bewusst ändern
Kam Ihr Chef schon mal zu Ihnen und hat in Ihrem Arbeitsvertrag mal eben kurz was geändert, weil ihn etwas störte oder er gerne etwas anderes im Vertrag hätte?
Ich hoffe nicht. Dann hätte er nämlich mit dem Obligationenrecht und vermutlich mit Ihnen ein Problem bekommen.
Genau das passiert aber oft in der Softwareentwicklung. Kontrakte werden im Affekt, nur kurz mal eben, geändert. Das hat aber gravierende Folgen. Verträge sind die zentralen Schnittstellen und sollen nur bewusst und überlegt geändert werden. In meinem Team gehen wir sogar so weit, dass Verträge nur gemeinsam und im Konsens geändert werden.
Solange die Verträge aber gerade neben der Implementierung hängen ist die Änderung nicht weit. Und die sind mir noch zu nah aufeinander wenn Sie in der gleichen Solution in verschiedenen Projekten hängen. Klick, klick und eine neue Methode ist drin – vermutlich aber nur kurz zu Testzwecken oder weil es schnell gehen muss, richtig?
The power of real component oriented architecture II - Fokus
Was hilft mehr als den Fokus bei einer Problemlösung zu wahren? Wie angenehm wäre es, wenn Sie einfach nur die Quelltextdateien sehen die zu Ihrem aktuellen Problem
gehören? Und nur die Unit Tests die sich darauf beziehen?Das ist das selbe wie Eric Evans uns mit Domain Driven Design nahe legt. Den Fokus auf die Domäne bewahren. Aber wie soll das gehen wenn das offene Projekt alles mixt?
Bei der echten Komponentenorientierung haben Sie genau dieses Problem nicht. Sie sehen was sie brauchen, nicht mehr, aber auch nicht weniger. Bei meiner täglichen Arbeit ist das ein Vorteil geworden, den ich nicht mehr missen möchte.
Physische Grenzen müssen her!
Was also ist zu tun um all die unbestrittenen Stärken der Komponentenorientierung zu nutzen (einige so bekannte Vorteile wie z.B. die Testbarkeit, Skalierbarkeit, Evolvierbarkeit, usw. muss ich wohl kaum noch zusätzlich benennen, dass haben andere schon zu genüge getan)? Dafür müssen physische Grenzen her. Der Quellcode muss anders organisiert werden. Nur so werden Kontrakte nicht mal eben geändert und man hat nicht monolithische Solutions mit hunderten Projekten und tausenden Quelltextdateien.
Microsoft verwendet dazu die Solution folders (rot markiert). Das ist aber meiner Meinung nach das falsche Strukturierungs-Mittel. Kontrakte, Implementierungen und verschiedene Komponenten mit verschiedenen Belangen sitzen immer noch zu nahe aufeinander. Entschuldigt das Bild aber ich möchte den Schmerz etwas vermitteln.
Wie also kann man diese physischen Grenzen ziehen?
Ganz einfach: Jede Komponentenimplementierung erhält eine einzelne Solution und jeder Kontrakt auch. Die Kontrakte kann man, wenn man möchte auch zusammenfassen. So sieht das dann in einer Ordnerstruktur aus:
Ganz einfach: Jede Komponentenimplementierung erhält eine einzelne Solution und jeder Kontrakt auch. Die Kontrakte kann man, wenn man möchte auch zusammenfassen. So sieht das dann in einer Ordnerstruktur aus:
Und in den einzelnen Solutions, als Kontrast zu vorher:
Das ist nenn ich überschaubar. Ich sehe was ich brauche. Ich kann ganz einfach meinen Fokus halten. Öffne ich diese Solution habe ich genau eine Implementierung für ein abgestecktes Problemgebiet vor mir. Und die Tests gleich dazu. So fällt mir das arbeiten viel einfacher.
Kein IDE Support
Leider erhält man von Visual Studio keine Unterstützung bei einem solchen Vorgehen. Bis zu einem gewissen Grad ist das auch in Ordnung. Schliesslich ist die „Hürde“ ja gewollt. Nur ist da im Vergleich zu vorher doch erheblich mehr Aufwand zu betreiben um ein neues Projekt zu initialisieren. Ist das mal getan hat man nur noch Mehraufwand zu bewältigen, wenn man neue Komponenten einführt.
Trotzdem beim Anlegen einer neuen Komponente sind immer folgende Schritte zu tun:
· Kontrakt-Projekt in der Kontrakt-Solution anlegen
· Umbiegen des Build-Verzeichnisses auf das gemeinsame Build-Verzeichnis
· Solution für die Komponentenimplementierung anlegen
· Umbiegen des Build-Verzeichnisses auf das gemeinsame Build-Verzeichnis
Das ist beinahe noch verschmerzbar. Viel mehr Aufwand kommt dann noch dazu, wenn man einen Schreibfehler in einem Komponentennamen gemacht macht und eine Komponente umbenennen möchte. Überall so viele Referenzen. Das kann durch ein Tool automatisiert werden. Dadurch wird vielleicht die Einstiegshürde herabgesetzt wirklich Komponentenorientiert zu arbeiten und keine monolithischen Riesen-Solutions mehr zu bauen.
Rettung naht – CAF
Mit der Unterstützung von Ralf Westphal mache ich mich auf zu einer Lösung des Problems. Wir starten das Projekt Component Architecture Factory (CAF). Der Gedanke dahinter ist simpel. In einer XML Datei beschreibe ich deklarativ meine Komponenten und ihre Abhängigkeiten. Der Rest kann CAF dann übernehmen.
Die Vision ist also, dass CAF direkt den Verzeichnisbaum aufbaut, die Solutions für die Kontrakte und Implementierungen baut, den Build Prozess zusammensteckt und das ganze auch gleich noch in ein Source Control Repository verpackt. Deklarativ die Architektur beschreiben und gleich ein Resultat in den Händen – klingt das nicht gut?
Ich werde hier weiter berichten, dranbleiben ;-)
