Framework oder Bibliothek

Dec 23 2022
Was ist der Unterschied und sollte uns das interessieren?
Wenn es um Abhängigkeiten geht, können beide Begriffe verwendet werden, manchmal in einer (gefährlichen) austauschbaren Weise. Ist React ein Framework oder eine Bibliothek? Was ist mit Bootstrap oder Lodash? Beides sind doch „Pakete“, oder? Sicher, aber sie haben definitiv nicht die gleichen Auswirkungen auf Ihre App.
Eine gerahmte Ansicht der Französischen Nationalbibliothek

Wenn es um Abhängigkeiten geht , können beide Begriffe verwendet werden, manchmal in einer (gefährlichen) austauschbaren Weise. Ist React ein Framework oder eine Bibliothek? Was ist mit Bootstrap oder Lodash ? Beides sind schließlich „ Pakete “, oder?

Sicher, aber sie haben definitiv nicht die gleichen Auswirkungen auf Ihre App.

Bibliotheken

Eine Bibliothek („bibliothèque“ auf Französisch, aber die meisten Franzosen sagen „librairie“, was auf Französisch eigentlich „Buchhandlung“ bedeutet, aber mit der englischen Aussprache von „library“ übereinstimmt) ist eine Reihe von Funktionen für allgemeine Zwecke (wie underscore.js ) . oder spezialisierte (wie moment.js ).

Sie rufen Bibliotheksfunktionen auf, wann immer Sie sie benötigen, so wie Sie Werkzeuge aus einer Toolbox auswählen. Sie erfordern keine Änderungen in Ihrem Softwaredesign .

Bei der Verwendung einer Bibliothek wird ein zwingender Aufruf ausgeführt

Proprietäre Anrufe

Als Abhängigkeit erfordern sie jedoch, dass Sie ihre proprietäre API aufrufen und so Ihren Code mit ihnen (oder möglicherweise sogar einer Version davon) „sperren“, sodass ein Bibliotheksaufruf eher so aussehen sollte:

In Wirklichkeit hängt Ihr Code von der API der Bibliothek ab

Diese Sperre nimmt mit der Anzahl der von Ihnen ausgegebenen Aufrufe zu: Je mehr Sie die Bibliothek aufrufen, desto stärker ist Ihr Code von ihr (oder einer Version davon) abhängig:

Je häufiger Sie die Bibliothek aufrufen, desto mehr wird Ihr Code mit proprietären Aufrufen „verschmutzt“.

Einziger Punkt der Abhängigkeit

Um eine solche Abhängigkeit jedoch einzuschränken, können Sie sie hinter einem Wrapper verstecken:

Durch die Verwendung eines Adapters bleiben Ihre Aufrufe bibliotheksunabhängig

Eine solche Hülle kann tatsächlich mehr als einem Zweck dienen. Abgesehen davon, dass Sie die Sperrung auf einen einzigen Punkt in Ihrer Codebasis reduzieren, können Sie dadurch Ihre eigene API für Aufrufer verfügbar machen. Eine solche Anpassung der Bibliothek umfasst nur die API, die für Ihre App sinnvoll ist, sowie I/O-Typen, die spezifisch sind, weder für Ihre App noch für die Bibliothek.

Was die Implementierung betrifft, ist Ihr Code jedoch Schritt für Schritt immer noch von dem der Bibliothek abhängig.

Geschäfts-API

Hoffentlich, wie der verstorbene David J. Wheeler zu sagen pflegte:

Alle Probleme in der Informatik können durch eine andere Indirektionsebene gelöst werden .

Tatsächlich können Sie eine solche Abhängigkeit vermeiden, indem Sie eine Schnittstelle hinzufügen :

Durch die Bezugnahme auf die API-Schnittstelle statt auf die Implementierung bleibt der App-Code unabhängig
  • Aufrufer sind von dieser API-Deklaration abhängig;
  • Der Adapter muss es implementieren (beachten Sie, dass dies auch das Verspotten von Bibliotheken beim Testen erleichtern würde).

Rahmenwerke

Frameworks („quadriciels“ im offiziellen Französisch, aber jeder sagt „Framework“) sind anders, da sie eine andere Art von Service bieten: Sie bieten an, Dinge für Sie zu verwalten, anstatt Sie entscheiden zu lassen, was zu tun ist.

Kontrolle übergeben

Dazu implementieren sie das Rückgrat (den „Rahmen“) einer Anwendung und lassen Sie die Lücken füllen. Aber diese Rohlinge bleiben an definierten Stellen und haben definierte Formen.

Das bedeutet, dass:

  • Die App beginnt mit dem Gerüst : Sie müssen das Lenkrad abgeben.
  • Da das Framework die App steuert, sind Sie nicht mehr derjenige, der Anrufe tätigt: Stattdessen werden Sie bei Bedarf vom Framework zurückgerufen .
„Rufen Sie uns nicht an, wir rufen Sie an“, so das Hollywood-Prinzip

Verträge

Natürlich hindert Sie nichts daran, manuell eigenen Code, eine Bibliothek eines Drittanbieters oder sogar eine Framework-API aufzurufen, aber auf eigene Gefahr . Dies kann wie erwartet funktionieren oder auch nicht. Frameworks haben Regeln , die Sie befolgen müssen, und wenn Sie gegen diese verstoßen, kann das Framework nicht für etwaige Fehler verantwortlich gemacht werden.

Normalerweise ermöglicht Ihnen ein Framework das Schreiben von Komponenten , die durch die Implementierung eines Vertrags in ihre Container passen :

Jede Komponente muss dem Rahmenvertrag entsprechen.

Der Container ist dann in der Lage, Ihren Code als Framework-kompatibles Softwarestück zu verarbeiten, dessen Lebenszyklus verwaltet werden kann, und ruft Sie zu Zeiten zurück, die für die Ausführung der einen oder anderen Operation relevant sind.

Wie Sie sehen, ist dies eine viel strukturellere Wahl als Bibliotheken für Ihr Anwendungsdesign: Alle Ihre Komponenten werden spezifisch für dieses Framework. Das wird weder portierbar (dh von einem anderen Framework nicht verstanden) noch interoperabel sein (dh eine Angular-Komponente wird kaum mit einer React-Komponente interagieren).

Man könnte jedoch argumentieren, dass das Adaptermuster verwendet werden könnte, um die Framework-Abhängigkeit zu begrenzen, so wie wir es getan haben, um die Abhängigkeit von Bibliotheken zu begrenzen:

Eine Dämmung von Rahmenbauteilen macht kaum einen Unterschied

Dies könnte genauso nützlich erscheinen, wenn die Abhängigkeitsrichtung dieselbe wäre. Dies ist jedoch nicht der Fall: Bibliotheksadapter nahmen früher die von der App benötigte Form an, während Komponentenadapter hier nur die Form annehmen können, die das Framework erwartet. Dadurch kann die vermeintlich „kostenlose“ App-Komponente nur den ursprünglichen Vertrag nachahmen (Lebenszyklus, Semantik, Granularität).

Innerhalb von Frameworks wären Komponentenadapter dann eine unnötige Schichtung.

Framework-Bibliotheken

Auch Bibliotheken können Frameworks einhalten. Anstatt eine API bereitzustellen, stellen sie Komponentenimplementierungen für ein bestimmtes Framework bereit.

Als Frameworks immer beliebter wurden, wurde eine Reihe von Framework-Bibliotheken verfügbar. Bei den meisten handelt es sich jedoch um Widgets: Beispielsweise wurden die Material Design- Komponenten von Android auf Web Components , Angular , React , Vue und sogar iOS- Frameworks portiert.

Standard-Frameworks

Jeder kann sich die enormen Kosten vorstellen, die mit der Portierung derselben Bibliothek (und ihrer Folgeversionen) auf jedes dieser Frameworks verbunden sind.

IBM hat hierfür eine Lösung entwickelt : Anstatt das Carbon Design System auf jedes der gehypten Frameworks der Vergangenheit, Gegenwart und Zukunft zu portieren, investierten sie in eine Portierung auf das Standard-Webkomponenten-Framework , das in jedem Kontext verwendet werden kann.

Dies ermöglicht nicht nur die Verwendung ihrer Komponenten aus Frameworks:

Die Webkomponente ist nur ein Teil der Ansicht der Framework-Komponente

Dieselben Komponenten können aber auch aus einer einfachen App heraus genutzt werden:

Auch in einfache Web-Apps können Webkomponenten als Tags eingefügt werden

Abschluss

Frameworks und Bibliotheken sind sehr unterschiedliche Optionen von Drittanbietern:

  • Frameworks stellen Ihnen Anwendungsentwürfe mit integrierten Diensten zur Verfügung, erzwingen jedoch vordefinierte Verträge zum Aufrufen Ihres Codes. Als solche implizieren sie eine starke Abhängigkeit .
  • Bibliotheken helfen Ihnen nicht beim Entwerfen Ihrer Anwendung, sondern können nur aufgerufen werden, wenn Sie sie benötigen. Sie können ein Design entwickeln, das die Abhängigkeit auf sie beschränkt.