Diskussion:Adapter (Entwurfsmuster)

message: Ich habe den Inhalt aus Hüllenklasse hier eingearbeitet, weil die Hüllenklasse m. E. nur ein anderer Name für den Objektadapter ist. --jpp ?! 12:44, 26. Jul 2006 (CEST)
thread_title:  Zusammengeführt mit Hüllenklasse 

message: Hallo,
ich hab noch einen kleinen Nachtrag zu den Klassenadaptern. Wenn man das GoF-Buch aufmerksam liest, dann fällt auf dass das Beispiel zum Klassenadapter ein C++ Feature benutzt das sich private Vererbung nennt. Das bedeutet, dass die Implementierung der Superklasse und nicht deren Interface an die Subklasse vererbt wird. Dies halt also mehr mit "Komposition" astatt "echter Vererbung" zu tun. Der Adapter besitzt so trotz der Vererbung nur ein Interface. Sprachen wie Java unterstützen weder Mehrfachvererbung (auf Klassenebene) noch private Vererbung. Es ist zwar "möglich" ein dem Klassenadapter änliches Konstrukt zu schaffen (über Vererbung und Implementierung eines Interfaces) aber ziemlich sinnfrei, da die so erstellte Klasse beide Schnittstellen implementiert. Klassenadapter sind also nur dann sinnvoll, wenn die Sprache private Vererbung unterstützt.
Der Punkt kommt mir hier doch ein bissel zu kurz. Bin ich der Einzige der das so sieht? 
Grüße, Ralf!
:Hi, unterschreibe deine Diskussionsbeiträge bitte immer mit „--~~~~“, dann bekommst du den Zeitstempel gratis. Zur Sache: Warum denkst du, dass eine Klasse, die zwei Schnittstellen implementiert, sinnfrei ist? Der Klient existiert ja normalerweise, bevor der Adapter implementiert wird (nur deshalb ist der Adapter ja nötig.) Also sollte der Klient auch nicht in Versuchung geraten, die falsche Schnittstelle zu verwenden. --j ?! 15:15, 21. Aug. 2008 (CEST)
replies: text:  Ich sage ja nicht, dass es nicht funktioniert. Aber nicht immer ist alles was funktioniert auch sinnvoll. Die Beschreibung des Adapter-Patterns laut GoF ist "Convert the interface of a class into another interface clients expect" und nicht "Mix two interfaces together so that all clients can use them". Es geht also bei dem Pattern (wie bei den Andern auch) darum die Schnittstelle "sauber" zu halten. Das Pseudo-UML Diagram im Buch ist diese Vererbung auch mit "implementation" gekennzeichnet. --Ralfg 21:06, 21. Aug. 2008 (CEST)
replies: text: Sobald ich Zeit finde, werde ich mir den entsprechenden Abschnitt im Originalbuch nochmal durchlesen. Kannst aber auch gerne jetzt schon den Artikel entsprechend präzisieren. --j ?! 11:29, 22. Aug. 2008 (CEST)
thread_title:  Klassenadapter 

message: zu „Hüllenklassen für primitive Datentypen“, 
„Die einfache Schreibweise und bessere Lesbarkeit geht auf Kosten einer erheblich schlechteren Ausführungsgeschwindigkeit.“
Sofern man dort, wo nur int benötigt wird (Schleifenzähler o.ä.) auch nur selbiges verwendet, und nur Integer, wo es unumgänglich ist, sollte keine merkliche Verlangsamung eintreten - allenfalls bei einem Interpreter; aber heutige VM sind eh' immer JIT (oder noch ausgefuchsteres)...
Wenn der Programmierer natürlich IMMER Integer Objekte verwendet, auch bei Schleifen/Berechnungen/..., dann muss der Interpreter schon kämpfen (sofern der zu-Bytecode-Compiler nicht optimiert hat). --arilou 11:31, 13. Apr. 2011 (CEST)
thread_title:  Geschwindigkeit 

message: Laut diesem Beitrag sind folgende Elemente aus Java Adapter:
* java.io.InputStreamReader(InputStream) - (returns a Reader)
* java.io.OutputStreamWriter(OutputStream) (returns a Writer)
* javax.xml.bind.annotation.adapters.XmlAdapter#marshal() and #unmarshal()
Kann mir das jemand erklären? Was ist der Klient, was der Adapter, was ist der Dienst? Was sind jeweils die Operationen? --Martin Thoma 11:54, 17. Jul. 2012 (CEST)
replies: text: Klient ist der, der das Ganze benutzt. Eine Klasse MyProgram beispielsweise. Ziel ist Reader, Adapter ist InputStreamReader und Dienst ist InputStream. Das ist eigentlich ziemlich klar, schätze ich. Das Pattern wird genau so verwendet, wie es im GoF-Book steht. Umgekehrt gibt es aber andere Patterns, die in abgewandelter Form verwendet werden. Im von dir verlinkten Beitrag wird z.B. behauptet, Arrays.asList() wäre eine AbstractFacttory. Inwieweit das so richtig ist, darüber könnte man sich streiten. Strukturell ist es nicht so. Da aber bei Patterns die Struktur eben nicht alles ist, könnte es ja immer noch eine Variante des Patterns sein. Dafür müsste aber die Intention zumindest die selbe sein. Das würde ich in dem Fall aber in Zweifel ziehen. Hier aber bei den Adaptern ist es ziemlich klar. Nur beim Beispiel mit dem XMLAdapter haben wir ne Variante des Patterns, die strukturell abweicht (aber die selbe Intention hat). --Der Hâkawâti ✉ 10:05, 18. Jul. 2012 (CEST)
replies: text:  Vielen Dank für die ausführliche Antwort! Ich habe noch das Bild hinzugefügt, falls jemand anderes die gleichen Fragen hat. --Martin Thoma 13:16, 18. Jul. 2012 (CEST)
thread_title:  Beispiele in Java