ComponentArchitecture

KomponentenArchitektur - Die neue Architektur von ZoPe3 erleichtert speziell neuen Entwickler den Einstieg

zusammengefasst bzw. �bersetzt von ZoPe3:ComponentArchitectureOverview - FlorianKonnertz, 04-19

unter Bearbeitung

Der Ansatz der Komponenten-Architektur

Die grundlegende Idee der ComponentArchitecture von Zope3 besteht in der Nutzung von components statt MehrfachVererbung um die Komplexit�t zu bew�ltigen. Hier sollen die Vorz�ge des komponenten-basierenden Ansatzes erkl�rt werden und wie dieser vom gewohnten Weg, Zope-Anwendungen zu erstellen abweicht.

Derzeit basiert Zope auf MehrfachVererbung um die Komplexit�t zu bew�ltigen. Die Verantwortlichkeiten von Objekten sind �ber viele einzelne MixInClasses? verteilt. Viele dieser MixInKlassen? ben�tigen SubClasses? um spezialisierte MetaDaten? oder Methoden f�r das Verhalten des MixIn? bereitzustellen. Die Klassen haben typischerweise eine gro�e Zahl von BasisKlassen?, viele einzelne MetaDaten? und spezielle Methoden, die nicht zur Kern-Funktionalit�t des Objekes beitragen, also keinen Zusammenhang damit haben. Au�erdem? f�llt unter die Verantwortlichkeit des Objekts typischerweise auch die Bereitstellung anderer InterFaces, wie zB. FTP interfaces.

Die Alternative dazu ist es, die Verantwortlichkeit �ber viele kooperierende Objekte zu verteilen, da so die Komplexit�t besser gemanagt werden kann.

Siehe hierzu die Abbildung 1 auf ZoPe3:ComponentArchitectureApproach - Sie illustriert den Unterschied zwischen der Vererbungs- und Komponenten-basierten Architektur.

Komponenten

Ein Problem bei der Verteilung der Verantwortlichkeiten in Abbildung 1 sind die Abh�ngigkeiten von verschiedenen Klassen. Man kann die PresentationClasses? ersetzen, um eine alternative Pr�sentation bereitzustellen, aber man kann die Funktionalit�t der Anwendung bzw. ContentClasses? nicht ersetzen, ohne die PresentationClasses? zu ver�ndern. Dies ist etwas �bertrieben dargestellt, da die PresentationClasses? wahrscheinlich von dem Verhalten der Klassen abh�ngig sind von denen sie basieren, und nicht von den konkreten Klassen. Die Verhaltens-Abh�ngigkeit kann mittels InterFaces ausgedr�ckt werden. Siehe hierzu Abbildung 2.

Abbildung 2 veranschaulicht die InterFaces. Die Funktionalit�t der Anwendung und die ContentClasses? realisieren diese Interfaces, die ihr Verhalten beschreiben. Sie verlassen sich auf diese InterFaces, nicht auf die speziellen Klassen. So wird es viel einfacher, Funktinalit�t und ContentClasses? zu ersetzen, es mu� nur eine Klasse bereitgestellt werden, die das InterFace? realisiert.

Das verbleibende Problem ist: Wie werden die einzelnen Komponenten zusammengebracht? Die Zope Komponenten-Architektur bietet eine Maschinerie die es relativ leicht macht, die kooperierenden Objekte zusammenzuh�ngen. In bedeutendem Ma�e? sind sind die Objekte verbunden mittels InterFaces (Abb.2). Dies bringt uns zu dem Konzept der "Komponenente".

In der Zope Komponenten-Architektur versteht man unter Komponente ein Objekt mit InterFaces die der IntroSpektion? m�chtig sind. (Speziell Objekte, die InterFaces implementieren, die unter ZoPe3:ZopeInterfaces definiert sind.)

Die Komponenten-Architektur bietet M�glichkeiten, verschiedene Arten von Komponenten zu finden basierend auf Interfaces und Namen. Wenn z.B ein Document content object traversiert wird um auf ein Web interface zuzugreifen und das Dokument im StructuredText?-Format zu editieren, so wird die STX PresentationComponent? herausgesucht basierend auf dem ContentInterface? DocumentInterface? und dem PresentationName? (zB.structuredText). Im Gegenzug wird das WebInterface von StructuredText? die StructuredTextDocument?-Komponente, die auf dem ContentInterface? DocumentInterface? basiert und entweder die ApplicationComponentInterface? StructuredTextSourceInterface? oder den ApplicationComponent? name (zB.structuredTextSource). Der Grund warum entweder Namen oder InterFaces verwendet werden wird an anderer Stelle erkl�rt. Es werden niemals Komponenten anhand der ComponentClass? herausgesucht, weil der Einschub verschiedener Implementierungen erleichtert werden soll.

Einige Details sind es wert, hier erw�hnt zu werden. Zum einen sind die Klassen in Abb.2 keine Komponenten. Die Instanzen der Klassen sind die Komponenten. Dies ist eine bedeutende Unterscheidung. (Klassen koennen Komponenten sein wenn die Klassen InterFaces implementieren. Zum Beispiel werden Klassen manchmal als FactoryComponent?-s genutzt, sie sind verantwortlich f�r die Erzeugung anderer Komponenten, den Instanzen der Klasse.) Zum zweiten: Es stellt sich die Frage , ob die PresentationClasses? in Abb.2 ein InterFace? implementieren. Tats�chlich ist dies der Fall. Sie implementieren ein WebPublishingInterface? und die Instanzen der Klasse sind also Komponenten.

Der Umstieg ist kein Mu�?

Der komponenten-basierende Ansatz bietet einige gute Vorteile gegen�ber dem vererbungs-basierenden Ansatz, aber Vererbung funktioniert noch genauso. Man mu� keine Komponenten benutzen, die vorhandenen Zope-Objekte werden weiter funktionieren. Ein hybrider Ansatz ist ebenso m�glich. Zum Beispiel h�tte man hier nur das Verhalten im Web aus der ZDocument? Klasse herausnehmen k�nnen.