In diesem Teil geht es darum, was Sie lernen, wenn Sie eine Programmiersprache lernen. Ich wünsche viel Spaß:

Kapitel 1: Einleitung / 1.1 Was ist eine Programmiersprache? / 1.1.2 Das Blech fliegt weg

Von alten Programmiersprachen hin zu neueren ändern sich also im wesentlichen zwei Dinge:

Zum einen werden die Bibliotheken, wird die API immer umfangreicher und leistungsstärker, so dass bei einer jüngeren, aktuelleren Sprache ein einziger Befehl bereits genügt, um eine Funktionalität in Gang zu setzen, die bei älteren Sprachen seitenlange Befehlsabfolgen benötigt hätte.

Und zum anderen werden die Programmierkonzepte logisch ausgefeilter. Die Vorstellungskraft des Programmierers ist heute mehr gefordert als dessen Akkuratheit im Detail. Wurde früher ein Programm wie ein starres Kochrezept Zeile für Zeile hintereinander abgearbeitet – und wurde auch der Programmierer trainiert dementsprechend zu denken – kommen heute Ereignisse ins Spiel (der Benutzer klickt einen Button) um die Ausführung von Code anzustoßen oder es werden ganze Codeteile von einer Ecke des Programms in eine andere verfrachtet, um dort parallel zu anderen ausgeführt zu werden. Der Programmierer kann sich besser um die Architektur des Hauses kümmern, weil ihm das kleinteilige Aufkleben von winzigen Kacheln im Bad jetzt von der Programmiersprache abgenommen wird. Nichts gegen Fliesenleger. Nur eben nicht in der Programmierung.

Bibliotheken, APIs und die Programmiersprache

Ich habe die Begriffe Bibliothek und API oben synonym benutzt, das kann man machen. Will man aber differenzieren, ist folgender Sprachgebrauch üblich:

Zunächst einmal gibt es die Programmiersprache, die an sich einen gewissen Sprachumfang hat. Dies schließt Variablen mit ein, Kontrollstrukturen (Schleifen und bedingte Ausführung), wie auch die Beschreibung von Klassen und dergleichen.

Dann gibt es Bibliotheken. Eine Bibliothek ist eine Ansammlung von Code, der in der Programmiersprache geschrieben ist, und der durch seinen Umfang und seine Struktur abstraktere Aufgaben wahrnehmen kann.

Eine gute Anschauung liefert Lego. Angenommen, man möchte sich ein Einkaufszentrum aus Lego bauen – ein großes Gebäude mit vielen kleinen Läden, zweistöckig, das ist eine Herausforderung.

Die Programmiersprache stellt die kleinsten Teile, die einzelnen Lego-Bausteine. Es gibt sie in sehr unterschiedlichen Formen und Farben, und alle sind so gestaltet, dass sie möglichst vielseitig verwendbar sind. Stellt sich über die Jahre heraus, dass neue Lego-Steine hilfreich wären, dann nimmt Lego diese Steine hoffentlich irgendwann neu ins Sortiment. Genauso wachsen Programmiersprachen über die Jahre und bekommen mit jeder neuen Version neue Sprachelemente verpasst – mit Glück die richtigen, um mit aktuellen Anforderungen besser umgehen zu können.

Zurück zum Einkaufszentrum. Das Beispiel eignet sich gut, weil hier ins Auge fällt, dass sich viele der Strukturen wiederholen. Zwei Stockwerke kann man einander so ähnlich aufbauen, dass sie zu angepassten Kopien einer Vorlage werden. Hat man die Vorlage einmal, kann man auch hundert Stockwerke nach dieser Vorlage bauen. Außerdem ähneln die einzelnen Läden einander sehr. Man könnte also eine anpassbare Vorlage für einen Laden schaffen. Dann gleichen sich die Türen, die Treppen, Toiletten, usw.

Aus Lego kann ich also eine Türvorlage bauen, dann hab ich Türen, eine Treppenvorlage, dann hab ich Treppen. Ich erstelle Vorlagen für alles, was sich wiederholt, und baue daraus die Vorlage für einen Laden. Und daraus die Vorlag für ein Stockwerk. All diese Vorlagen zusammen ergeben in der Programmierung eine Bibliothek, eine Ansammlung von wiederverwendbarem Code. Mit dem zusätzlichen Vorteil, dass die Dinge, mit denen man beim Programmieren umgeht, tatsächlich mit nur einem Befehl kopiert werden können und nicht immer wieder, Stück für Stück aus Einzelteilen zusammengebaut werden müssen.
Wenn jemand so eine Bibliothek schreibt, dann besteht sie aus Teilen zum „internen Gebrauch“ und aus Teilen, die dem Benutzer dieser Bibliothek präsentiert werden sollen. Ist die Bibliothek sehr abstrakt und liefert nur die fertigen Läden aus, dann ist zum Beispiel die Gestaltung der Türen nur für die interne Nutzung gedacht, in der Programmierung heisst das privat (englisch: private). Die Auslieferung der Läden ist aber öffenlich (englisch: public).

Die Sammlung all dessen, was an einer Bibliothek public ist, nennt sich API, ausgeschrieben Application Programming Interface. Das ist das Benutzerinterface der Bibliothek (der Benutzer ist in diesem Fall der Programmierer).

Foundation, Cocoa und .NET

Die für die Programmierung wichtigsten Bibliotheken, sind diejenigen, die mit der Programmiersprache selbst ausgeliefert werden und so eng mit der Sprache verbunden sind, dass man ohne sie praktisch nicht programmieren kann. Sie sorgen dafür, dass man Fenster auf dem Bildschirm darstellen, auf Dateien zugreifen kann und komplexe Datentypen zur Verfügung hat.

Unter Windows ist das die sogenannte Windows API (gespeichert u.a. in der kernel32.dll, wobei dll für Dynamic Link Library steht, einer Bibliothek also), vor allem aber das .NET Framework, das einen abstrakteren, modernen Zugriff auf die Windows-Funtionen ermöglicht.

Und auf Apple-Hardware sind das die von Apple bereitgestellten Bibliotheken, deren bekannteste Vertreter wohl Foundation, Cocoa und Core Data sein dürften. Auch Apple nennt diese großen, umfangreichen Bibliotheken Frameworks, obwohl dieser Begriff auf technischer Ebene nicht ganz korrekt ist.

Möchte man lernen, wie man iPhone Apps schreiben kann, dann besteht etwa 90% des Lernaufwandes darin, sich mit diesen grundlegenden Bibliotheken auseinanderzusetzen und nur etwa 10% verwendet man auf die Programmiersprache. Die Programmiersprache selbst hat man also vergleichsweise schnell erlernt.

Spricht man allerdings davon, dass man eine Programmierprache wie zum Beispiel Swift lernt, dann meint man in der Regel, dass man die nötigen Bibliotheken gleich mit lernt, weil die Sprache ja kein Selbstzweck ist. Nichtsdestotrotz ist die Programmiersprache auch die Grundlage, auf der aufbauend die Bibliotheken überhaupt erst Sinn machen.

Was diesen Kurs betrifft, wird er dort, wo es Berührungspunkte gibt, auch im reinen Swift-Teil auf die API eingehen, grundsätzlich jedoch die Bibliotheken nachgelagert besprechen und hierbei die bis dorthin erworbenen Swift-Kenntnisse voraussetzen.

Was ist privat und was ist öffentlich?

Noch einmal zurück zu dem öffentichen Anteil einer Bibliothek, API genannt, und deren privatem Anteil:

Die Sprache, die vor Swift zur Programmierung von Apple Hardware verwendet wurde, ist Objective-C. Und Objective-C hat eine merkwürdige Eigenschaft: Zwar kann man in der Sprache selbstgeschriebene Befehle als private oder public deklarieren, jedoch lassen sich die als private deklarierten Befehle dennoch von außen aufrufen. Der Benutzer einer Bibliothek kann also auf die intern verwendeten und nicht für die Öffentlichkeit bestimmten Befehle zugreifen und sie für sich nutzen.

Und da dies eine Eigenschaft der Sprache selbst ist – also auf grundlegender Ebene eingebaut wurde – kann selbst Apple technisch nichts gegen diese Aufrufe unternehmen. Eine Versuchung für einen Programmierer, der zum Beispiel über eine Internetrecherche herausgefunden hat, dass die Lösung für ein Programmierproblem ein solcher privater Befehl sein kann. Benutzt er ihn und tut der, was die Recherche ergab, läuft für den Programmierer während der Programmierung alles wunderbar.

Will er das Programm dann aber in den App Store einstellen, wird die Annahme von Apple wegen der Verwendung eines „privaten API-Aufrufs“ verweigert. Die Verwendung der „privaten API“ ist sogar einer der sichersten Wege zu einer App Store Ablehnung, da sie von Apple zwar wie gesagt technisch nicht unterbunden, sehr wohl aber automatisiert geprüft werden kann.

Der Begriff „private API“ ist dabei natürlich ein Widerspruch in sich, weil die API per Definition nur die öffentlichen Befehle umfasst – Apple hat das aber nicht abgehalten.

In anderen Sprachen gibt es Schlüsselwörter wie public oder private, die man einfach vor die selbstgeschriebenen Befehle setzt, und die von der Sprache dann so strikt respektiert werden, dass ein ungewollter Aufruf technisch gar nicht möglich ist. Sie denken jetzt vielleicht: Macht doch alles öffentlich, juchuu, Freiheit, jeder kann benutzen was er will! Aber die Verwendung von private dient nicht dem Verstecken oder der Geheimhaltung, sondern der Stabiliät und Übersichtlichkeit des Codes – etwa, wenn aus hundert vorhandenen Befehlen in einer Bibliothek die zehn herausgehoben werden, über die eine einfache, klare und sichere Verwendung der Bibliothek möglich ist. Ohne dass der Benutzer vorher in stundenlanger Arbeit eine tiefere Kenntnis über die innere Struktur der Bibliothek aufbauen muss.

Eine wichtige Frage ist darum: Verfügt Swift über Schlüsselwörter wie public oder private?

Die Antwort ist: nein. Ärger noch als bei Objective-C, kann die Privatheit eines Befehls nicht einmal markiert werden, geschweige denn, dass sie technisch durchgesetzt wird. In Swift ist alles public.

Aber: Da dies eine sehr wichtige Frage ist, hat sich einer der Swift-Entwickler bei Apple klar dazu geäußert: Grundsätzlich mache Apple keine Versprechungen bezüglich zukünftiger Entwicklungen, aber dies sei eine Ausnahme. Swift werde Möglichkeiten zur Zugriffskontrolle bekommen.

Kapitel 1.1.2: Das Blech fliegt weg

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.