Der Martin: Software-Architekturen: Adapter vs. Interface

Beitrag lesen

Hi,

Nun ist allerdings zwischen "Fremdsystem" und Schnittstelle ein Adapter eingebaut worden.

weil man das Konzept allgemein halten möchte, nehme ich an.

Die Beweggründe des Diagrammerstellers wollen mir dabei nicht so recht einleuchten.

Mir schon: Die Schnittstelle möchte man meistens anhand existierender Standards oder anhand eigener Anforderungen definieren - jedenfalls nicht anhand von konkreten Eigenschaften des Fremdsystems, wenn man davon ausgeht, dass dieses Fremdsystem jederzeit austauschbar ist.

Außerdem stelle ich mir die Frage, wodurch ich diese beiden Dinge in der späteren Software klar von einander unterscheiden kann.

Durch eine klare Modularisierung. Angenommen, "Buckel IT Systems" würde in ihren Projekten eine selbst entwickelte Schnittstelle zum Datenaustausch zwischen ihren eigenen Komponenten verwenden. Klar, dass diese Schnittstelle alternativ auch zur Kommunikation mit Fremdsystemen verwendet wird, deren Schnittstelle etwas anders definiert ist - aber dann müsste ein Stück Software her, das zwischen "Buckel IT Systems" und dem Fremdsystem "übersetzt". Ein Gerätetreiber wäre ein vertrautes Beispiel für einen solchen Adapter. Er vermittelt zwischen der Anwendung oder dem Betriebssystem, die beide nicht hardwareabhängig sein *wollen*, und der Hardware, die nun einmal spezielle Eigenschaften hat.

Meiner Meinung nach sind hier die Grenzen derart fließend, dass ich das Ganze zusammenpacken würde.

In manchen Fällen ist das ja auch sinnvoll. Wenn man es mit der Modularität und Interoperabilität aber wirklich ernst nimmt, müsste man solche Stellen klar getrennt halten.

Ciao,
 Martin

--
why the heck do you jerk think, that wir ein doppelposting nicht bemerken, wenn you zwischendurch the sprache wechselst?
  (wahsaga)