Bibliotheken vs. Frameworks – Was ist der Unterschied?

Die Wikipedia-Seite für eine Code-Bibliothek definiert sie als:

„In der Informatik ist eine Bibliothek eine Sammlung von nichtflüchtigen Ressourcen, die von Computerprogrammen verwendet werden, oft für die Softwareentwicklung. Dazu können Konfigurationsdaten, Dokumentation, Hilfedaten, Nachrichtenvorlagen, vorgefertigter Code und Unterprogramme, Klassen, Werte oder Typspezifikationen gehören.“

Im Vergleich dazu die Definition eines Frameworks:

„In der Computerprogrammierung ist ein Software-Framework eine Abstraktion, in der Software, die generische Funktionalität bereitstellt, durch zusätzlichen, vom Benutzer geschriebenen Code selektiv verändert werden kann und so anwendungsspezifische Software bereitstellt.

Es bietet eine Standardmethode zur Erstellung und Bereitstellung von Anwendungen und ist eine universelle, wiederverwendbare Softwareumgebung, die als Teil einer größeren Softwareplattform bestimmte Funktionen bereitstellt, um die Entwicklung von Softwareanwendungen, Produkten und Lösungen zu erleichtern.“

Es gibt viel zu entpacken, aber wenn Sie mit beidem gearbeitet haben, können Sie wahrscheinlich schon erkennen, dass eine Code-Bibliothek im Allgemeinen verwendet wird, um ein bestimmtes Problem zu lösen oder ein bestimmtes Merkmal zu Ihrem Programm hinzuzufügen.

Ein Framework hingegen bietet Ihnen etwas viel Allgemeineres und Wiederverwendbares. Wenn Sie den Wikipedia-Eintrag weiter lesen, werden Sie feststellen, dass drei Dinge ein Framework von einer Bibliothek unterscheiden.

Inversion der Kontrolle

Bibliotheken fügen sich in Ihren Code ein, Ihr Code fügen sich in ein Framework ein.

Der erste große Unterschied zwischen einem Framework und einer Bibliothek besteht darin, wer die Kontrolle über den Entwicklungsprozess hat.

Bei einer Code-Bibliothek ruft ein Entwickler im Allgemeinen die Bibliothek auf, wann immer er es für richtig hält. Ein Framework erfordert im Allgemeinen, dass der Entwickler vollständig in seinen Arbeitsablauf eintaucht.

Das Ergebnis ist, dass es sich oft so anfühlt, als ob das Framework die Kontrolle über den Entwicklungsprozess hat und nicht der Entwickler. Das ist eine Umkehrung der Kontrolle! Dies wird üblicherweise als eine Variante des Folgenden vereinfacht:

  • Bibliothek: Rufen Sie uns an, um die Aufgabe zu erledigen.
  • Framework: Du rufst uns nicht an, wir rufen dich an.

Aufgrund dieser Umkehrung der Kontrolle sind Frameworks viel eigenwilliger und auch der Grund, warum sie so viel für Entwickler tun können.

Eigenwillig bedeutet, dass Frameworks viele Entscheidungen darüber treffen, wie der Code geschrieben wird, wo die Dateien liegen und möglicherweise sogar den Namen dieser Dateien.

Making these assumptions allows for the usage of the paradigm of convention over configuration which allows developers to skip the process of app configuration in exchange for following certain conventions (such as putting certain files in certain folders, etc.).

Ruby on Rails is a popular framework for developing web applications.

Look at a framework like Ruby on Rails. It is often considered highly opinionated. Wenn Sie ein neues Projekt mit Ruby on Rails erstellen, werden zahlreiche Ordner und Dateien mit reichlich vorgefertigtem Code generiert.

Die meiste Arbeit des Entwicklers wird wahrscheinlich im app-Ordner erledigt (hier befinden sich die Unterordner für Models, Views und Controller), aber es gibt noch jede Menge anderen Code in diesem Rails-Projekt, der dazu dient, Ihre Anwendung zum Laufen zu bringen.

Außerdem hat Ruby on Rails einen bestimmten Arbeitsablauf, den es von Ihnen erwartet. Wenn Sie ein User-Modell in Rails erstellen, geht es davon aus, dass es mit einem UsersController verbunden ist.

Rails möchte, dass diese Dateien auf eine bestimmte Art und Weise benannt werden (user.rb für das Model und users_controller.rb für den Controller) und dass sie sich in ihren jeweiligen Ordnern befinden.

Wenn Sie von Rails‘ Workflow abweichen, werden Sie frustriert sein, wie und warum Ihr Code nicht funktioniert. Work with it and everything just seems to magically work.

A large part of that magic (some do refer to it as Rails magic) is just all of that pre-written code working in the background. You fill in the models, views, controllers, and draw some routes, and Rails will take care of linking everything up correctly.

ChartJS lets you make some really beautiful charts.

Compare this to Chart.js which is a JavaScript library for creating really beautiful charts.

Sie entscheiden, wann und wo Sie Chart.js aufrufen, und obwohl es stimmt, dass Sie bei der Erstellung eines neuen Diagramms Felder ausfüllen müssen (Sie werden die Art des Diagramms, Beschriftungen, Farben usw. angeben wollen), wird Ihr Arbeitsablauf nicht kontrolliert.

Chart.js kümmert sich nur um die Informationen, die zum Zeichnen eines Diagramms erforderlich sind; der Rest Ihres Codes ist ihm völlig egal.

Erweiterbarkeit

Ein wichtiges Konzept in der objektorientierten Programmierung ist das Prinzip der offenen und geschlossenen Struktur.

Ein einfaches Beispiel hierfür ist die Vererbung von Klassen, die es einer Unterklasse ermöglicht, die für sie erforderlichen Funktionen und Merkmale hinzuzufügen, ohne dass der Code der übergeordneten Klasse direkt geändert werden muss.

Die Erweiterbarkeit ermöglicht es einem Entwickler, einem Framework neue Merkmale hinzuzufügen oder das Verhalten vorhandener Merkmale an seine Bedürfnisse anzupassen, ohne den Quellcode zu ändern.

Gute Frameworks sind mit Blick auf die Erweiterbarkeit entwickelt worden. Sie bieten die allgemeine Funktionalität, die für die Entwicklung einer allgemeinen Anwendung benötigt wird, lassen sich aber für spezifische Ergänzungen und Änderungen, die für eine bestimmte Anwendung erforderlich sind, offen.

Wenn ein Framework nicht erweiterbar wäre, wäre es in seiner Funktionalität ziemlich eingeschränkt, und das würde es weniger attraktiv machen, es zu erlernen.

Wenn man bei den obigen Beispielen bleibt, gibt es mehrere Erweiterungen für das Ruby on Rails-Framework, um zusätzliche Funktionen wie die Benutzerauthentifizierung hinzuzufügen.

Wenn Rails diese Erweiterungen nicht hätte, würde es die Möglichkeiten, die man mit ihm machen kann, stark einschränken. Fairerweise muss man sagen, dass Chart.js auch viele Plugins und Erweiterungen hat. Diese ermöglichen Dinge wie das Zeichnen zusätzlicher Arten von Diagrammen.

Der Unterschied ist hier jedoch viel weniger sichtbar, da Frameworks allgemeine Funktionalität bieten, sollten sie mit Blick auf Erweiterbarkeit gebaut werden, damit app-spezifische Funktionen implementiert werden können.

Eine Bibliothek muss nicht unbedingt mit Blick auf Erweiterbarkeit gebaut werden, ihr Hauptzweck ist es, eine bestimmte Aufgabe zu erfüllen.

Nicht veränderbarer Code

Dieses Konzept ist glücklicherweise viel leichter und einfacher zu erklären. Die kurze und einfache Antwort ist, dass Frameworks einen Haufen Code generieren und man diesen Code in den meisten Fällen nicht anfasst.

Zurück zu Rails, wie zuvor erklärt, verbringt ein Entwickler im Allgemeinen die meiste Zeit mit der Arbeit am App-Ordner. Der Entwickler wird in der Regel den bereits geschriebenen Code nicht ändern oder löschen.

Schreibe einen Kommentar