Warum wird Transparenz im Composite-Muster gegenüber Sicherheit bewertet?

Question

Ich habe gerade über die Composite pattern erfahren. So wie ich es verstehe, besteht die Hauptidee darin, Kanten und Knoten eines Baumes einheitlich zu behandeln. Dies bedeutet, dass die „Transparenz“ der Struktur mehr als die „Sicherheit“ bewertet wird, um uns zu so etwas wie dieser führenden:

ich das Konzept zu verstehen, aber denken kann, nicht von Situationen, in denen die Sicherheit zu opfern für Transparenz wäre eine gute Wahl zu machen. Mit anderen Worten, in welchen Fällen brauchen wir Transparenz so sehr, dass wir bereit sind, ein so ernsthaftes Opfer zu bringen?

Answer 1

Es wäre zutreffender zu sagen, dass Transparenz in einigen Diskussionen über das Composite-Muster, einschließlich der ursprünglichen Beschreibung durch die Viererbande, über Sicherheit geschätzt wird. Aber die Gang of Four Beschreibung erkennt den Kompromiss und other influential discussions are more pro-safety. Wie auch immer, hier ist der Fall für Transparenz:

Sicherheit (Methoden nicht anwendbar Blatt nur in Composite-Deklaration) Kosten hat:

• Der Kunde eines Baumes von sicheren Komponenten muss überprüfen, ob jede Komponente a Komposit, wenn es den Baum durchquert (möglicherweise unter Verwendung der externen Polymorphie-Technik, die auf Seite 168 des GoF-Buchs gezeigt ist). Entweder muss jeder Client des Baums diese Überprüfung implementieren oder, wenn die Überprüfung in einem Besucher oder dergleichen bereitgestellt wird, muss er mit dieser Komplexität umgehen.

• Komponenten-Implementierer müssen wählen, ob jede Komponente ein Leaf oder Composite ist, und ihren Code ändern, wenn sie ihre Auswahl ändern.

Der Wert der ‚Transparenz‘ (Einheitlichkeit der Blatt- und Composite, das heißt alle Baummanipulationsmethoden in Komponente erklärt) ist, dass die Kosten der Sicherheit minimiert werden.

Transparenz wird wertvoller, wenn eine der folgenden Bedingungen erfüllt sind:

• Leafs sind selten oder gar nicht vorhanden. In einem UI-Toolkit könnte es beispielsweise möglich sein, untergeordnete Elemente zu einer beliebigen Komponente hinzuzufügen (auch zu einer Komponente, die normalerweise wenig für Kinder verwendet, wie ein Kontrollkästchen) und zu erwarten, dass sie intelligent gerendert werden. Die visuelle Flexibilität, die dadurch bereitgestellt wird, könnte den zusätzlichen Aufwand wert sein, der von den Entwicklern benötigt wird, die ansonsten Leafs wären, und eine Standardimplementierung in Component könnte diesen zusätzlichen Aufwand minimieren.

• Viele Verwendungen des Baums müssen nicht zwischen Leafs und Composites unterscheiden. In einem UI-Toolkit können Operationen wie das Zeichnen beispielsweise Leafs und Composites einheitlich behandeln, indem sie über die Liste der untergeordneten Elemente jeder Komponente mit der Länge Null iterieren.

• Die Laufzeit (Speicher und CPU) Kosten jeder Komponente mit einer Liste von Kindern ist relativ zum Rest des Programms niedrig.

Wenn die oben wahr ist, zahlt Gleichförmigkeit aus mehr: Kunden des Baumes weniger tun müssen, um den Baum zu verwenden, und Situationen, in denen die Benutzerfreundlichkeit Kunden zu Schwierigkeiten geraten, sind selten. Dies kann bei UI-Komponenten oft der Fall sein: Der einzige Zeitpunkt, an dem sich ein Client des Baums Gedanken darüber machen muss, ob etwas zusammengesetzt ist oder nicht, kann sein, wenn er den Baum erstellt (hinzufügt), zu welchem ​​Zeitpunkt er weiß was alle Betonkomponenten sind sowieso.

Java Swing hat diese Wahl getroffen: JComponent enthält add Methoden. Entwickler müssen sie nur nicht mit JComponents verwenden, die keine Kinder unterbringen, was für viele Komponenten offensichtlich ist (wiederum wie Checkboxen).

Wenn eine der entgegengesetzten Situationen der Fall ist, wird die Unterscheidung zwischen Leafs und Composites wertvoller und die erhöhte Komplexität der Verwaltung eines sicheren Baums wird lohnenswert. Wenn Leafs üblich sind und/oder viele Clients des Baums zwischen Leafs und Composites unterscheiden müssen, aber die Typen "transparent" sind und die Unterscheidung nicht ermöglichen (vielleicht hätte die GoF diese Auswahl eher als undurchsichtig denn als transparent bezeichnet), dann ist es wahrscheinlicher, dass ein Kunde einen Fehler macht. Wenn Listen von Kindern zu teuer sind, sollten Component-Implementierer auswählen, ob jede Komponente ein Leaf oder Composite ist.