Framework vs. Toolkit vs. Bibliothek

Question

Was ist der Unterschied zwischen einem Framework, einem Toolkit und einer Bibliothek?

Answer 1

Der wichtigste Unterschied, und in der Tat der Definition Unterschied zwischen einer Bibliothek und einem Framework ist Umkehrung der Kontrolle .

Was bedeutet das? Nun, es bedeutet, dass wenn Sie eine Bibliothek aufrufen, Sie die Kontrolle haben. Aber bei einem Rahmenwerk ist die Kontrolle umgekehrt: die Rahmenwerk ruft Sie an. (Dies wird als Hollywood-Prinzip bezeichnet: Rufen Sie uns nicht an, wir rufen Sie an.) Dies ist so ziemlich die Definition eines Rahmens. Wenn es keine Umkehrung der Kontrolle gibt, ist es kein Rahmenwerk. (Ich schaue dich an, .NET!)

Im Grunde ist der gesamte Kontrollfluss bereits im Framework enthalten, und es gibt nur eine Reihe von vordefinierten weißen Flecken, die Sie mit Ihrem Code ausfüllen können.

Eine Bibliothek hingegen ist eine Sammlung von Funktionen, die Sie anrufen können.

Ich weiß nicht, ob der Begriff Toolkit wirklich gut definiert ist. Allein das Wort "Kit" scheint eine Art von Modularität zu suggerieren, d. h. eine Reihe unabhängiger Bibliotheken, aus denen man auswählen kann. Was unterscheidet dann ein Toolkit von einem Haufen unabhängiger Bibliotheken? Integration: Wenn man nur einen Haufen unabhängiger Bibliotheken hat, gibt es keine Garantie, dass sie gut zusammenarbeiten, während die Bibliotheken in einem Toolkit so konzipiert wurden, dass sie gut zusammenarbeiten - man muss nur nicht todos von ihnen.

Aber das ist wirklich nur meine Interpretation des Begriffs. Anders als Bibliothek und Framework, die sont gut definiert ist, glaube ich nicht, dass es est eine weithin akzeptierte Definition von Werkzeugsatz .

Answer 2

Martin Fowler erörtert den Unterschied zwischen einer Bibliothek und einem Framework in seinem Artikel über Umkehrung der Kontrolle :

I was ein Framework von einer Bibliothek unterscheidet. Bibliothek unterscheidet. A Satz von Funktionen, die Sie aufrufen können , diese Tage in der Regel organisiert in Klassen. Jeder Aufruf erledigt etwas Arbeit und gibt die Kontrolle an den Client zurück.

A Entwurf, in den weiteres Verhalten eingebaut ist. Um es zu verwenden, müssen Sie i Ihr Verhalten an verschiedenen Stellen im dem Rahmenwerk e indem Sie Ihre eigenen Klassen einfügen. Die Der Code des Frameworks ruft dann Ihren Code an diesen Stellen auf .

Kurz gesagt: Ihr Code ruft eine Bibliothek auf, aber ein Framework ruft Ihren Code auf.

Answer 3

Diagramm

Wenn Sie eher visuell lernen, finden Sie hier ein Diagramm, das die Sache verdeutlicht:

(Credits: http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than-frameworks )

Answer 4

Einführung

Es gibt verschiedene Begriffe, die sich auf Sammlungen von zusammengehörigem Code beziehen, die sowohl historische (vor 1994/5 für die Zwecke dieser Antwort) als auch aktuelle Implikationen haben, und der Leser sollte sich beider bewusst sein, insbesondere wenn er klassische Texte über Computer/Programmierung aus der historischen Ära liest.

Bibliothek

Sowohl historisch als auch aktuell ist eine Bibliothek eine Sammlung von Code, der sich auf eine bestimmte Aufgabe oder eine Reihe eng verwandter Aufgaben bezieht, die ungefähr auf der gleichen Abstraktionsebene arbeiten. Sie hat in der Regel keinen eigenen Zweck und ist dazu bestimmt, von Client-Code verwendet (konsumiert) und in diesen integriert zu werden, um den Client-Code bei der Ausführung seiner Aufgaben zu unterstützen.

Werkzeugkasten

Historisch gesehen ist ein Toolkit eine stärker fokussierte Bibliothek mit einem definierten und spezifischen Zweck. Heute ist dieser Begriff in Ungnade gefallen und wird fast ausschließlich (nach Kenntnis des Autors) für grafische Widgets und GUI-Komponenten verwendet. Ein Toolkit arbeitet meist auf einer höheren Abstraktionsebene als eine Bibliothek und verwendet oft selbst Bibliotheken. Im Gegensatz zu Bibliotheken wird Toolkit-Code oft dazu verwendet, die Aufgaben des Client-Codes auszuführen, wie z. B. das Erstellen eines Fensters, das Ändern der Größe eines Fensters usw. Die niedrigeren Abstraktionsebenen innerhalb eines Toolkits sind entweder fest vorgegeben oder können vom Client-Code auf eine bestimmte Art und Weise bearbeitet werden. (Man denke nur an den Fensterstil, der entweder festgelegt ist oder im Voraus durch den Client-Code geändert werden kann).

Rahmenwerk

Früher bestand ein Framework aus einer Reihe miteinander verbundener Bibliotheken und Module, die entweder in "allgemeine" oder "spezifische" Kategorien unterteilt waren. Allgemeine Frameworks sollten eine umfassende und integrierte Plattform für die Erstellung von Anwendungen bieten, indem sie allgemeine Funktionen wie plattformübergreifende Speicherverwaltung, Multi-Threading-Abstraktionen, dynamische Strukturen (und generische Strukturen im Allgemeinen) zur Verfügung stellten. Historische allgemeine Frameworks (ohne Dependency Injection, siehe unten) wurden fast durchgängig durch polymorphe Templates (parametrisierte) in OO-Sprachen, wie z. B. die STL für C++, oder in Paketbibliotheken für Nicht-OO-Sprachen (garantierte Solaris-C-Header) ersetzt. Allgemeine Frameworks arbeiteten auf unterschiedlichen Abstraktionsebenen, aber durchgängig auf niedrigem Niveau, und verließen sich wie Bibliotheken darauf, dass der Client-Code seine spezifischen Aufgaben mit ihrer Hilfe ausführt.

Spezifische" Frameworks wurden in der Vergangenheit für einzelne (aber oft weitreichende) Aufgaben entwickelt, wie z. B. "Command and Control"-Systeme für industrielle Systeme und frühe Networking-Stacks, die auf einer hohen Abstraktionsebene arbeiteten und wie Toolkits für die Ausführung der Aufgaben des Client-Codes verwendet wurden.

Gegenwärtig wird die Definition eines Frameworks stärker fokussiert und das an anderer Stelle erwähnte Prinzip der "Inversion of Control" als Leitprinzip herangezogen, so dass sowohl der Programmfluss als auch die Ausführung vom Framework übernommen werden. Frameworks sind jedoch nach wie vor entweder auf eine bestimmte Ausgabe ausgerichtet, z. B. eine Anwendung für ein bestimmtes Betriebssystem (z. B. MFC für MS Windows), oder für allgemeinere Zwecke (z. B. Spring Framework).

SDK: "Software-Entwicklungs-Kit"

Ein SDK ist eine Sammlung von Werkzeugen, die den Programmierer bei der Erstellung und Bereitstellung von Code/Inhalten unterstützen, die speziell für eine bestimmte Plattform oder auf eine bestimmte Art und Weise entwickelt wurden. Ein SDK kann einfach aus einer Reihe von Bibliotheken bestehen, die nur auf eine bestimmte Art und Weise vom Client-Code verwendet werden müssen und die normal kompiliert werden können, bis hin zu einer Reihe von Binärwerkzeugen, die Binäranlagen erstellen oder anpassen, um ihre (die des SDK) Ausgabe zu produzieren.

Motor

Eine Engine (im Sinne der Codesammlung) ist eine Binärdatei, die maßgeschneiderte Inhalte ausführt oder Eingabedaten auf irgendeine Weise verarbeitet. Spiel- und Grafik-Engines sind vielleicht die häufigsten Nutzer dieses Begriffs und werden fast immer mit einem SDK verwendet, das auf die Engine selbst abzielt, wie z. B. das UDK (Unreal Development Kit), aber es gibt auch andere Engines, wie z. B. Suchmaschinen und RDBMS-Engines.

Oft, aber nicht immer, erlaubt eine Engine ihren Kunden nur den Zugriff auf einige ihrer Interna. Meistens, um entweder eine andere Architektur anzusteuern, die Darstellung der Ausgabe der Engine zu ändern oder zu Tuningzwecken. Open-Source-Engines sind per Definition offen für Kunden, um sie nach Bedarf zu ändern und zu modifizieren, und einige proprietäre Engines sind vollständig festgelegt. Die weltweit am häufigsten verwendeten Engines sind jedoch mit Sicherheit JavaScript-Engines. Eingebettet in jeden Browser gibt es überall eine ganze Reihe von JavaScript-Engines, die JavaScript als Eingabe entgegennehmen, verarbeiten und dann zum Rendern ausgeben.

API: "Anwendungsprogrammierschnittstelle"

Der letzte Begriff, auf den ich antworte, ist ein persönliches Ärgernis von mir: API wurde historisch verwendet, um die externe Schnittstelle einer Anwendung oder Umgebung zu beschreiben, die selbst in der Lage war, unabhängig zu laufen oder zumindest ihre Aufgaben nach der anfänglichen Ausführung ohne Eingreifen des Clients auszuführen. Anwendungen wie Datenbanken, Textverarbeitungsprogramme und Windows-Systeme stellten der externen Schnittstelle einen festen Satz interner Hooks oder Objekte zur Verfügung, die ein Client dann aufrufen/verändern/verwenden konnte, um Funktionen auszuführen, die auch die ursprüngliche Anwendung ausführen konnte. Die APIs unterschieden sich darin, wie viele Funktionen über die API verfügbar waren und wie viel von der Kernanwendung vom Client-Code (wieder)verwendet wurde. (Eine Textverarbeitungs-API kann beispielsweise erfordern, dass die gesamte Anwendung im Hintergrund geladen wird, wenn jede Instanz des Client-Codes ausgeführt wird, oder vielleicht nur eine der verknüpften Bibliotheken; wohingegen ein laufendes Fenstersystem interne Objekte erstellt, die von ihm selbst verwaltet werden, und Handles an den Client-Code zurückgibt, die stattdessen verwendet werden können.

Gegenwärtig ist der Begriff API sehr viel weiter gefasst und wird häufig zur Beschreibung fast aller anderen Begriffe in dieser Antwort verwendet. Die gängigste Definition dieses Begriffs ist, dass eine API eine vertraglich festgelegte externe Schnittstelle zu einer anderen Software (Client-Code zur API) bietet. In der Praxis bedeutet dies, dass eine API sprachabhängig ist und eine konkrete Implementierung hat, die von einer der oben genannten Codesammlungen bereitgestellt wird, wie z. B. einer Bibliothek, einem Toolkit oder einem Framework. In einem speziellen Bereich, z. B. bei Protokollen, unterscheidet sich eine API von einem Protokoll, das ein allgemeinerer Begriff für eine Reihe von Regeln ist. Eine individuelle Implementierung eines bestimmten Protokolls/einer Protokollsuite, die eine externe Schnittstelle für andere Software bereitstellt, wird jedoch meistens als API bezeichnet.

Bemerkung

Wie bereits erwähnt, haben sich die historischen und aktuellen Definitionen der oben genannten Begriffe verschoben, was auf Fortschritte im wissenschaftlichen Verständnis der zugrundeliegenden Computerprinzipien und -paradigmen sowie auf das Aufkommen bestimmter Softwaremuster zurückzuführen ist. Insbesondere die grafischen Benutzeroberflächen- und Fenstersysteme der frühen neunziger Jahre haben dazu beigetragen, viele dieser Begriffe zu definieren, aber seit der effektiven Hybridisierung von Betriebssystemkern und Fenstersystem für Massenbetriebssysteme (außer vielleicht Linux) und der massenhaften Einführung von Dependency Injection/Inversion der Kontrolle als Mechanismus zur Nutzung von Bibliotheken und Frameworks mussten diese Begriffe ihre jeweilige Bedeutung ändern.

---

P.S. (Ein Jahr später)

Nachdem ich über ein Jahr lang sorgfältig über dieses Thema nachgedacht habe, lehne ich das IoC-Prinzip als den entscheidenden Unterschied zwischen einem Framework und einer Bibliothek ab. Es gibt eine große Anzahl von populären Autoren, die sagen, dass es so ist, aber es gibt eine fast ebenso große Anzahl von Leuten, die sagen, dass es nicht so ist. Es gibt einfach zu viele "Frameworks", die IoC NICHT verwenden, um sagen zu können, dass es das definierende Prinzip ist. Eine Suche nach eingebetteten oder Mikrocontroller-Frameworks zeigt eine ganze Reihe von Frameworks, die IoC NICHT verwenden, und ich glaube, dass die .NET-Sprache und CLR ein akzeptabler Abkömmling des "allgemeinen" Frameworks ist. Zu sagen, dass IoC das definierende Merkmal ist, ist für mich einfach zu starr, um es zu akzeptieren, und lehnt alles ab, was sich als Rahmenwerk anbietet, das der oben erwähnten historischen Darstellung entspricht.

Für Details zu Nicht-IoC-Frameworks siehe, wie oben erwähnt, viele eingebettete und Mikro-Frameworks, sowie jedes historische Framework in einer Sprache, die keinen Callback durch die Sprache bietet (OK. Callbacks können für jedes Gerät mit einem modernen Registersystem gehackt werden, aber nicht vom durchschnittlichen Programmierer), und natürlich das .NET-Framework.

Answer 5

En Antwort von Barrass ist wahrscheinlich die vollständigste. Die Erklärung könnte jedoch noch deutlicher ausfallen. Die meisten Menschen übersehen die Tatsache, dass es sich um verschachtelte Konzepte handelt. Lassen Sie es mich also für Sie erläutern.

Beim Schreiben von Code:

• irgendwann entdecken Sie Codeabschnitte, die sich in Ihrem Programm wiederholen, und überarbeiten diese in Funktionen/Methoden .
• Wenn Sie ein paar Programme geschrieben haben, werden Sie irgendwann feststellen, dass Sie Funktionen, die Sie bereits erstellt haben, in neue Programme kopieren. Um Zeit zu sparen, bündelt man diese Funktionen in Bibliotheken .
• Schließlich müssen Sie jedes Mal, wenn Sie bestimmte Bibliotheken verwenden, dieselbe Art von Benutzeroberfläche erstellen. Also refaktorisieren Sie Ihre Arbeit und erstellen eine Werkzeugkasten die es Ihnen ermöglicht, Ihre Benutzeroberflächen einfacher aus generischen Methodenaufrufen zu erstellen.
• Schließlich haben Sie so viele Anwendungen geschrieben, die dieselben Toolkits und Bibliotheken verwenden, dass Sie eine Rahmenwerk die bereits eine generische Version dieses Boilerplate-Codes enthält, so dass Sie nur noch das Aussehen der Benutzeroberfläche gestalten und die Ereignisse behandeln müssen, die sich aus der Benutzerinteraktion ergeben.

Damit sind die Unterschiede zwischen den Begriffen im Grunde genommen vollständig erklärt.