turgar: Software-Architekturen: Adapter vs. Interface

Hallo,

ich versuche mich gerade dem Thema der Software-Architekturen anzunäheren. Allerdings ist der Umfang einer solchen Thematik gewaltig.

Deshalb wollte ich erst einmal kleinere Ausschnitte davon betrachten um einen Einstieg in das Ganze zu finden.
Zwei dieser Ausschnitte sind Adapter und Interfaces.

Worin liegen die Unterschiede?
Welche Eigenschaften sollte ein Stück Code haben, dass ich es als das eine oder als das andere identifizieren kann?

Mag mir jemand hierzu ein paar Denkanstöße geben?

Danke für eure Meinungen.

  1. Hi,

    Zwei dieser Ausschnitte sind Adapter und Interfaces.
    Worin liegen die Unterschiede?

    der Begriff "Adapter" ist mir im Zusammenhang mit Software noch nicht begegnet, Interface dagegen schon. Nein, das soll jetzt nicht der entscheidende Unterschied sein - es heißt nur, dass ich den Unterschied etwas abstrakter erklären muss. ;-)

    Welche Eigenschaften sollte ein Stück Code haben, dass ich es als das eine oder als das andere identifizieren kann?
    Mag mir jemand hierzu ein paar Denkanstöße geben?

    Ein Interface ist eine Schnittstelle mit klar definierten Spezifikationen, sei es Hardware oder Software. Ein Interface ist zum Beispiel die Menge aller von außen aufrufbaren, dokumentierten Funktionen/Methoden eines Softwaremoduls/einer Klasse, einschließlich der an dieser Schnittstelle verwendeten Datentypen (manchmal auch API genannt).

    Ein Adapter ist dagegen etwas, das zwischen zwei unterschiedlichen Interfaces mit ähnlichem Funktionsumfang vermittelt. In der Hardware kennen wir Adapter z.B. als passives Zwischenstück von einem Stecker-Standard auf einen anderen, oder als aktives Zwischenstück, etwa als Umsetzer zwischen RS232 und USB.
    In der Software stelle ich mir unter einem Adapter etwas vor, das zwischen zwei Software-Interfaces oder Datenformaten vermittelt. Das kann im einfachsten Fall ein Programm sein, das Dateien von einem Format ins andere konvertiert, aber auch ein Plugin für einen Player, das etwa ankommende Videodaten in einem fremden Format in Echtzeit in MPEG2 umcodiert, so dass dieser Player sie abspielen kann (sehr konstruiertes Beispiel).

    So long,
     Martin

    --
    Nicht jeder, der aus dem Rahmen fällt, war vorher im Bilde.
    1. Toll, dass ihr euch alle so für das Thema interessiert :)

      Im Moment habe ich hier ne Skizze eines künftigen Systems.
      Darin enthalten sind solch elementare Dinge wie der Anwendungskern, die Datenbank, Dialoge, etc.
      Ebenfalls enthalten sind Adapter und Schnittstellen.
      Nachbarsysteme sollen mit dem Kern über eine Schnittstelle kommunizieren.
      Soweit so gut.
      Nun ist allerdings zwischen "Fremdsystem" und Schnittstelle ein Adapter eingebaut worden.
      Die Beweggründe des Diagrammerstellers wollen mir dabei nicht so recht einleuchten. Außerdem stelle ich mir die Frage, wodurch ich diese beiden Dinge in der späteren Software klar von einander unterscheiden kann.
      Meiner Meinung nach sind hier die Grenzen derart fließend, dass ich das Ganze zusammenpacken würde.

      1. echo $begrüßung;

        Nun ist allerdings zwischen "Fremdsystem" und Schnittstelle ein Adapter eingebaut worden. Die Beweggründe des Diagrammerstellers wollen mir dabei nicht so recht einleuchten.

        Warum nicht? Ich kenne ja das Diagramm nicht und kann auch nur raten. Auch ein Adapter muss eine Schnittstelle bieten, damit man ihn ansprechen kann. Ob diese Schnittstelle ein Interface im OOP-Sinne implementiert, sei mal dahingestellt. Der Adapter setzt ja nur zwischen einer bestimmten Schnittstelle in eine andere um. Passt etwa die ursprüngliche Schnittstelle nicht zum Fremdsystem? Oder ist der Adapter nur ein "zur Vorsorge" eingeschobenes Teil, der vielleicht nichts macht außer 1:1 durchzureichen, den er bei Änderungen an einer der beiden Seiten auszutauschen gedenkt? Ob das in dem Fall sinnvoll ist, vermag ich ohne Kenntnis des Systems nicht zu beurteilen.

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

        An ihren Aufgaben oder Wirkungsweisen, gelegentlich auch an der Namensgebung. Du erkennst in einer Arbeitsweise (Verhalten) oder einem Aussehen (Struktur) ein bestimmtes Muster, das zu einem bereits ausformulierten Software-Pattern passt.

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

        Mund und Kopf hängen auch irgendwie mit fließenden Grenzen zusammen, haben aber mehr oder weniger definierbare Aufgaben. Es ist schon sinnvoll, je nach Bedarf beides getrennt zu betrachten oder auch nicht. Eine abschließendes stets gültige Einsortierung wirst du nicht hinbekommen.

        echo "$verabschiedung $name";

      2. 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)
  2. Hallo,

    http://www.phpbar.de/w/Interface kennst du?

    Gruß

    jobo

  3. echo $begrüßung;

    Zwei dieser Ausschnitte sind Adapter und Interfaces.
    Worin liegen die Unterschiede?

    Nun, ihre Definition kann man nachlesen, unter anderem in der Wikipedia: Adapter (Entwurfsmuster) und Schnittstelle (objektorientierte Programmierung).

    Mag mir jemand hierzu ein paar Denkanstöße geben?

    Wobei hast du konkret Schwierigkeiten? Wenn du die nicht benennen kannst, versuch mal in eigenen Worten zu beschreiben, wofür die beiden Begriffe stehen. (So dass man daraus Rückschlüsse auf dein Verständnisproblem schließen kann.)

    echo "$verabschiedung $name";