# data[].attributes.body
Muster beschreiben Lösungsvorschläge für in der Umwelt beständig wiederkehrende Probleme mit Allgemeingültigkeit. Hierbei ist das Muster nicht die konkrete Lösung selbst sondern beschreibt lediglich den Kern der Lösung. Das Gegenteil eines Musters ist das Antimuster, welches ein Vorgehen beschreibt, was vermieden werden sollte, da es zu größeren Problemen führen kann.

Muster beinhalten immer eine bestimmte Situation, in der sie Anwendung finden können (Kontext), eine Problembeschreibung und eine optimale Lösung für das beschriebene Problem. Nach diesen Stichpunkten soll nun das Proxy-Muster anhand des Dampfens einer Lokomotive erläutert werden. Das Proxy-Muster gehört zu den Entwurfsmustern und beeinflusst somit die Architektur einer Software.

# data[].attributes.body
Würde man alle Funktionen der Lokomotive in die zugehörige Klasse integrieren, so würde diese ein angemessenes Maß an Komplexität übersteigen. Gerade im Fall von Berechtigungsprüfungen würde der Umfang einer Klasse rasant ansteigen, da diese meist sehr komplex sind. Deshalb ist es sinnvoll manche Funktionalitäten auszulagern. An dieser Stelle kommt der Proxy ins Spiel. Der Proxy ist ein Stellvertreter eines Objekts und erlaubt die Implementierung weiterer Funktionalitäten, wie beispielsweise einer Sicherheitsschicht.

# data[].attributes.body
In diesem Beispiel möchte der Nutzer seine Gartenbahn steuern und die Lokomotive dampfen lassen. Hierfür bedient er seine App und klickt beispielsweise auf einen Button. Nun muss der Client mit der Lokomotive kommunizieren und ihr vermitteln, dass sie dampfen soll. Der Client muss dadurch die Ausführung einer Funktionalität der Lokomotive veranlassen.

# data[].attributes.body
Die Grundidee eines Proxys lässt sich in der folgenden Darstellung erkennen.

Wie bereits beschrieben, versucht der Client eine Funktionalität des Objekts zu nutzen (dampfen). Anstatt aber mit dem richtigen Objekt (RealSubject) zu kommunizieren, wird ein individueller Stellvertreter dazwischen geschaltet (SubjectProxy). Um diese Kommunikation zu ermöglichen, wird eine Schnittstelle benötigt (Subject). Dieses Interface bildet die Superklasse, von welcher der SubjectProxy und das RealSubject erben. Der Client nutzt somit eine Operation des RealSubjects, ohne Kenntnis über dessen Implementation zu besitzen. Die Anweisung zu dampfen wird von dem SubjectProxy an das RealSubject weitergeleitet. Das RealSubject ist für die eigentliche Ausführung der Operation verantwortlich, füllt die leeren abstrakten Methoden des Interfaces und dampft. Durch diese Vorgehensweise wird dem Client vorgespielt er würde mit dem eigentlichen Subject interagieren.

# data[].attributes.body
Nach der Erklärung der Vorgehensweise, soll eine Bewertung des Musters vorgenommen werden. Zum einen kann die Komplexität des Subjects durch die Einführung eines Interfaces reduziert werden. Zum anderen können die Netzwerkkommunikation, die Berechtigungsprüfung und der fachliche Kontext voneinander getrennt werden. So könnte der Proxy weitere Funktionalitäten zur Sicherheitsprüfung beinhalten, während das RealSubject lediglich den fachlichen Kontext und die Hauptfunktionalität gewährleistet. Jedoch kann man hier argumentieren, dass die allgemeine Komplexität der Architektur ansteigt, da eine weitere Zugriffsebene hinzugefügt werden muss, wodurch die Antwortzeit vergrößert werden könnte.

# data[].attributes.body
Häufig wird das Proxy-Muster in die Verwandtschaft des Facade-Musters eingeordnet. Die Fassade ist eine einheitliche Schnittstelle, um eine komplexe Menge an Funktionalitäten in Form einer Black Box für den Client zur Verfügung zu stellen. Ähnlich wie beim Proxy-Muster, interagiert der Client mit einer Schnittstelle, welche die Aufgabe an ein Subsystem weiterleitet. Ein großer Unterschied hierbei ist jedoch, dass die Klassen- und Methodennamen bei dem Proxy-Muster exakt denen des RealSubjects entsprechen müssen, da der Proxy diese referenziert. Bei der Fassade können diese Namen beliebig gewählt werden, sollten jedoch ihre Sinnhaftigkeit behalten.

# data[].attributes.body
Goll J. (2014): Architektur- und Entwurfsmuster der Softwaretechnik. Springer Vieweg, Wiesbaden.

Balzert H. (2011): Lehrbuch der Softwaretechnik: Entwurf, Implementierung, Installation und Betrieb. Spektrum Akademischer Verlag.

Eilebrecht K., Starke G. (2019): Patterns kompakt. IT kompakt. Springer Vieweg, Berlin, Heidelberg.