Da Reflektion Code die Ausführung von Vorgängen ermöglicht, die in nicht reflektierendem Code unzulässig wären, wie z. B. der Zugriff auf private Felder und Methoden, kann die Verwendung von Reflektion zu unerwarteten Nebenwirkungen führen, die Code dysfunktional machen und die Portabilität zerstören können. Reflektierender Code bricht Abstraktionen und kann daher das Verhalten mit Upgrades der Plattform ändern. Ein schnelles Java Reflection-Beispiel, um Ihnen zu zeigen, wie reflektionsmittel aussieht: Wenn Sie genauer hinsehen, sehen Sie, dass die Kopplung von MainClass zu PartsFactory verschoben wurde. Obwohl PartsFactory jetzt an IPartsInventory und seine Implementor-Objekte gekoppelt ist, wirkt sich die Kopplung nicht annähernd so negativ darauf aus, wie MainClass bei der Implementierung des Factory-Musters in Abbildung 2 betroffen war, da sich der Klassenzusammenhalt nicht verschlechtert hat. Mit anderen Worten, PartsFactory bleibt fokussiert. Wenn Sie diese hartcodierte Kopplung aus dem Werk entfernen könnten, würden Sie die niedrigstmögliche Kopplung und den höchsten Zusammenhalt in allen Klassen erreichen, aus denen die Implementierung des Factory-Musters besteht. Bleiben Sie dran; als nächstes werde ich beschreiben, wie Reflexion Sie ziemlich nahe an dieses erhabene Ziel bringen kann. Weitere Informationen finden Sie unter: www.magalix.com/blog/kubernetes-patterns-the-reflection-pattern Im Factory-Muster gibt es einen Kunden, eine Fabrik und ein Produkt.

Der Client ist jedes Objekt, das ein Objekt aus der Factory benötigt. Das Produkt ist das Objekt, das von der Factory an den Client zurückgegeben wird. Werfen Sie einen Blick auf den Code in der abstrakten Fabrik PartsFactory und den Betonfabriken MonitorInvFactory und KeyboardInvFactory in Abbildung 3. Obwohl dies ein vernünftiger Ansatz zur Implementierung des Factory-Musters ist, weist er einige Mängel auf. Überlegen Sie, wie sich die Kopplung manifestiert und inwieweit sie in diesem Muster vorhanden ist. Die InventoryMgr-Klasse sieht gut aus (Kupplung ist niedrig), da sie davor geschützt ist, von einer der Betonfabriken zu wissen. Die Aufnahme neuer Betonfabriken in der Zukunft wird dies nicht beeinflussen. InventoryMgr wird auch von den verschiedenen Implementierungen von IPartsInventory entkoppelt, indem ein Verweis auf die Schnittstelle anstelle eines konkreten Objekts verwendet wird. Also, was ist das Problem? Anschließend wird die Reflektion erneut verwendet, um den entsprechenden Setter für das Element – -eigenschaft > abzubekommen und seinen Wert auf den angegebenen Wert festzulegen. Eine Sprachunterstützende Reflektion bietet eine Reihe von Features, die zur Laufzeit verfügbar sind und andernfalls in einer Sprache auf niedrigerer Ebene nur schwer zu erreichen wären. Einige dieser Funktionen sind die Fähigkeiten: In der Regel sollten Objekte nur dann andere Objekte erstellen, wenn sie beabsichtigen, eine Nachricht oder Nachrichten an diese Objekte zu senden, es sei denn, ihre Hauptverantwortung liegt in der Erstellung und Rückgabe dieser Objekte. Fabriken zum Beispiel sind solche Klassen.

Eine nachteilige Wirkung unnötiger Kopplung ist ein geringerer Zusammenhalt. MainClass hat auch seinen Zusammenhalt verringert, da es sich angesichts seiner Rolle als Nachrichtenspediteur nicht darum kümmern sollte, welche Betonfabriken für die Bearbeitung der Anfrage benötigt werden. Sein Fokus sollte einfach darin liegen, eine Anfrage zu stellen, sie möglicherweise neu zu verpacken und zur weiteren Verarbeitung an InventoryMgr zu senden. Wie Sie später sehen werden, hilft Reflexion, unnötige Kopplung zu entfernen und den Zusammenhalt in allen Klassen zu verbessern, die am Factory-Muster teilnehmen.