Tobster schrieb:
Dann begründe doch bitte deine Behauptung.
Für mich, jemand der damit sein Geld verdient, ist Objektiv-C anfänglich kryptisch und es gibt wenig Literatur dafür.
Aber ich lasse mich gerne vom gegenteil überzeugen. Wenn ich nicht für alles offenwäre wäre ich falsch in meinem Beruf.
Also her mit den Infos.
Ich gehe davon aus, dass wir hier über Mac-Programmierung reden und das zu OS X. Zitiere mal aus der Einleitung zu meinem Cocoa-Workshop in der MACup.
--------------
In Apples Dokumentation zu Cocoa (sprich Koko) steht vieles, nur eines nicht, nämlich warum Cocoa so heißt. So haben wir recherchiert und sind auf KidSim gestoßen, dem einst bei Apple entwickelten Prototyp einer Programmierumgebung für Kinder. Das Projekt wurde später in Cocoa umbenannt, aber dann nicht mehr weiter verfolgt. Der Name war also frei und nun ist auch klar, warum die Programmierumgebung von OS X Cocoa getauft wurde. Zumindest Apple-Entwickler assoziieren damit den Begriff kinderleicht.
Der Wahrheit etwas näher kommen die in Programmiererkreisen beliebten Akronyme. „Complements Objective-C On Apples“ (ergänzt den Apple um Objective-C) heißt auch, das eine neu Programmiersprache zu erlernen ist. Diese ist zwar relativ einfach, aber bestimmt nicht kinderleicht.
„Chasing Objective-C Objects Around” verdeutlicht, dass man anfangs sehr viel Zeit damit verbringen wird, unter Hunderten von Objekten mit Tausenden von Methoden die richtigen zu finden. Und noch ein kleiner Dämpfer für die Anhänger plattformunabhängiger Programmierung: Cocoa heißt auch „Can Only Compile On Apples“.
Warum Cocoa?
Anhand von Abbildung 1, dem in der Apple-Dokumentation gezeigten Systemmodel von OS X, können Sie erkennen, wo Cocoa angesiedelt ist.
Aqua ist das, was jeder Anwender sieht und nutzt, sprich, die Bedienoberfläche der OS-X-Applikationen. Darunter liegt Classic, eine Umgebung in der die meisten alten Programme laufen. Daneben sehen Sie die API (Application Programming Interface) Carbon, Cocoa und Java.
Carbon-Programme sind solche, die ursprünglich für das Mac OS (OS 9) entwickelt und dann an OS X angepasst wurden. Sie laufen unter beiden Betriebssystemen, vorausgesetzt die Carbon-Bibliothek ist unter Mac OS 9 installiert.
Das Umschreiben von Classic- in Carbon-Programme ist relativ einfach, kostet aber Ressourcen und Geschwindigkeit und nutzt nicht alle Möglichkeiten von OS X aus. Deshalb rät Apple, neue Programme in Cocoa zu schreiben. Tatsächlich gibt es sogar viele Anbieter, die mit Carbon begonnen und später ihre Programme auf native Cocoa-Applikationen umgeschrieben haben.
Alternativ zu Cocoa kann man auch Java nutzen, doch davon raten wir ab. Erfahrene Java-Programmierer argumentieren zwar, dass sie sich damit das Erlernen von Objective-C ersparen können, doch das spart wenig. Der Aufwand liegt im Erlernen der Frameworks (wir kommen noch darauf zurück) und die sind in Objective-C dokumentiert. Ansonsten sind Java-Programme langsamer beim Start und im Betrieb, weil alle Methodenaufrufe über die so genannte Java-Bridge erst in Cocao-Aufrufe übersetzt werden müssen.
Bliebe noch AppleScript Studio zu erwähnen, das im Prinzip zwischen Aqua und Cocoa angesiedelt ist und das auch über eine Zwischenschicht (ein Framework) mit Cocoa kommuniziert. ASS reicht für viele Applikationen, wird aber arg langsam, wenn viel gerechnet oder mit großen Datenmengen umgegangen werden muss.
Auf der nächsten Ebene im Systemmodel schlägt das Grafik-Herz des Macintosh, nämlich das Window- and Grafiksystem Quartz einschließlich der Unterstützung von QuickTime und OpenGL.
Darwin schließlich ist der UNIX-Kern des Betriebssystems, der unter anderem für das Multitasking und die Unterstützung mehrerer Prozessoren sorgt.
Altbewährt
Cocoa ist nicht neu, denn es basiert auf NeXTStep, dessen Entwiclung 1987 begann. Seine Eltern leugnet Cocoa nicht, denn noch heute beginnen alle Namen mit NS, beispielsweise NSWindow, NSButton.
Programmiert wird Cocoa in Objective-C, einer Sprache, die zuerst mit ANSI-C kompatibel ist und deshalb ohne weiteres erlaubt, bewährte Funktionen aus C- oder C++ zu übernehmen. Darüber hinaus wurde die Sprache jedoch kräftig Richtung dynamischer Objektorientierung erweitert und das stark angelehnt an die Programmiersprache Smalltalk.
Tatsächlich bestehen viele Cocoa-Programme zu einem großen Teil aus diesen etwas gewöhnungsbedürftigen Sprachelementen, doch eines können wir Ihnen versprechen. Wenn Sie das Prinzip verstanden haben, werden sie es lieben und nicht mehr missen wollen.
Bliebe noch, einen wesentlicher Vorteil des alten NeXTStep von 1987 zu erwähnen, nämlich dass seinerzeit die Computer nicht besonders leistungsfähig waren. Deshalb wurde sehr viel Wert auf Geschwindigkeit einschließlich effizienter Entwicklung und kompakten Code gelegt. Damit überzeugen Cocoa-Programme auch noch heute.
Frameworks
Cocoa besteht im Wesentlichen aus 2 Klassenbibliotheken, von Apple Frameworks genannt. Wenn Sie im Projekt Builder (kommt gleich) unter „Help“ den Menüpunkt „Cocoa Help“ wählen, sehen Sie unter dem Titel „Reference Documtation/Objective-C Framework Reference“ die beiden Rubriken „Application Kit“ und „Foundation“.
Im Application-Framework finden Sie 122 Klassen mit Namen wie „NSButton“ oder „NSText“ also alles, was die Bedienoberfläche einer Cocoa-Applikation ausmacht. Der Umgang mit diesen Klassen gestaltet sich recht einfach. Nur wenigen Zeilen Code reichen, um beispielsweise einen Button auf Klicks des Anwenders reagieren zu lassen.
„Foundation“ hingegen mit derzeit 117 Klassen ist für die Grundlagen zuständig, zum Beispiel das Dateisystem (NSFileManager ) oder den Umgang mit Strings (NSString). Hier finden Sie aber auch Klassen wie NSTimer oder gar NSMachBootstrapServer.
----------------
Ansonsten: Literatur zu Cocoa/Objective-C gibt es massenhaft, ich persönlich kenne rund 1 Dutzend Bücher.
Java kenne ich, nutze ich auch manchmal. Java selbst ist syntaktisch gesehen eine C-Variante. Der große Unterschied: Java nimmt den Programmierer an die Hand und hindert ihn daran, bei Rot die Straße zu überqueren. Der C-Programmierer darf das, muss es aber nicht tun.
Objective-C bietet einen guten Kompromiss. z.B. bewirkt ein ungültiger Index einer NSArray-Instanz einem Compiler-Fehler. Bei der Speicherverwaltung kann alles selbst tun, hat sie dafür aber auch selbst im Griff. Man kann aber auch "convinience methods" wählen und damit Cocoa die Speicherbeschaffung/Freigabe überlassen. Auch letztere Methode ist effizienter als die Garbage Collection in Java, weil die Freigabe beim nächsten Eintritt in die "main run loop" erfolgt (und wenn das zu spät ist, legt man seinen eigenen Autorelease-Pool an).
