Ich denke es ist mal an der Zeit meine Eindrück, über die Welt der Entwicklung, aus Apples Auge, ein paar Worte zu verlieren. Im Rahmen meiner Weiterbildung beschäftige ich mich seit 1.5 Jahren mit C/C++. Java habe ich in den letzten Jahren auch programmiert, jedoch sehr wenig. Die meisten Zeilen Code habe ich in PHP und Perl geschrieben – bis jetzt.

Seit nun etwas mehr als 6 Monaten programmiere ich immer wieder etwas in Objective-C. Das Resultat sind zahlreiche Codeschnippsel welche in einem Verzeichnis “Experimente” in meinem Subversion Repository liegen. Effektiv ist eine iPhone App einen kurzen Schritt vor seiner Vollendung.
Der Anfang in Objective-C war steinig, verwirrend und meine Kopfhaut war anfänglich ziemlich wund vom vielen Kratzen. Der Syntax und Aufbau des Codes lässt sich schwer mit dem von C++ vergleichen. Nach langem schwertun wurde mir auch bewusst, dass es komplett falsch ist, diese beiden Sprach miteinander zu vergleichen! Objective-C hat seinen Ursprung schliesslich auch nicht in C++ sondern in C. Alles bereits vorhandene Programmierwissen ausgeblendet, startete ich einen zweiten Versuch mit der Sprache klar zu kommen. Es funktionierte!

Objective-C ist eine “menschenfreundliche” Programmiersprache. Sich ständig wiederholende Methoden, wie z.b. Setter/Getter Methoden wurden komplett vereinfacht. Hier sei angemerkt, dass ich nur von Objective-C 2 spreche!
Was ein C++ oder Java Programmierer unter Interfaces verstehen würde sind bei Apples Sprache Protokolle. Diese sind als Vertrag mit dem Programmierer zu verstehen. Ein Protokoll definiert Methoden die zwingend und solche die optional implementiert werden müssen resp. können. Hält sich der Entwickler nicht daran wird er sich mit dem Compiler in die Haare kriegen.
Wesentlich anderst ist der Aufruf von Methoden einer Klasse. Diese werden übrigens nicht mehr strikt in public, private,protected, virtual kategorisiert. Vielmehr unterscheidet man unter Instanz- und Statischen Methoden. Die Parameter einer Methode werden zwingend beschrieben. Dies macht den Code für den Menschen lesbar, als würde er einen Satz lesen.

[APIObjekt sendeAnfrage:anfrage anUrl:url];

Wobei “sendeAnfrage” und “anUrl” keinen Einfluss auf den Code haben. Sie beschreiben ausschliesslich den Methodenaufruf resp. dessen Parameter.

Bemerkenswert ist auch die gewonnene Dynamik dank den Selektoren. Mit diesen können Nachrichten, so werden Methodenaufrufe genannt, an Klassen verschickt werden. Sprich, eine Methode dynamisch aufgerufen werden. Wobei auch erst überprüft werden kann ob die entsprechende Klasse überhaupt auf diese Nachricht antworten kann.
Ebenfalls möchte ich an diesem Punkt noch die Kategorien erwähnen. Angenommen der String Klasse von Cocoa fehlt eine tolle Funktion die ich meinem Programm nutzen möchte, musste ich bis jetzt diese Klasse spezifizieren und dann diese in meinem Code verwenden. Im schlimmsten Fall würde dies bedeuten, dass ich tausende von Codezeilen durchsuchen und meine Klasse anstelle der alten einsetzen müsste. Mit Kategorien kann ich neue Methoden zu bestehenden Klassen anghängen. Somit sind diese Methoden ohne erbrechtliche Geschichten überall in meinem Code vorhanden. Cool, nicht?

Programmieren in Objective-C bedeutet Spass! Schönen Code zu schreiben wird somit einiges einfacher. Nun zur Schattenseite… Ja, es gibt tatsächlich eine!
Speichermanagement wird GROSS geschrieben in Objective-C. Es gibt drei Möglichkeiten seinen Arbeitsspeicher sauber zu halten.

• Manuelles aufräumen des Speichers
• Autoreleasepools, welche die Objekte anhand ihres internen Zählers eliminieren.
• Garbage-Collection

Letzteres wird von den eingefleischten Apple Entwicklern verteufelt zudem gibt es in den iOS Geräten kein GC! Wird beim programmieren nicht äusserst sorgfältig auf den Speicher aufgepasst, beisst einem sein eigenes Programm ganz sicher bald in den Allerwertesten! Ist es soweit, und bei jedem wird dies der Fall sein, greift man gerne auf die Analyse Tools von XCode zurück!

Fazit: Objective-C 2.0 hat einiges vom Zauberstaub der Zukunftsfee abgekriegt! Aber einfach so mal Objective-C lernen ist nicht… Dafür ist die Sprache zu komplex! Hat man sich mit der Sprache angefreundet findet man schnell gefallen an Apples Cocoa Framework. Dieses bietet für – fast – alle Situation einen schnuckelige Klasse bereit. Leider sind diese wirklich zum teil nur schnuckelig. Fehlende Methoden für z.b. Base64 Encoding, HMAC Verschlüsselung und fehlende API Klassen für XML-RPC und REST-API, verhindern eine innige, heisse Beziehung mit Cocoa!
Glücklicherweise findet man im Internet viele fertige Klassen, die dieses Defizit irgendwie, mit viel Klebeband, aufheben.
Noch ein letztes Wort zur Entwicklungsumgebung XCode. Jeder, der mit der Version 3.x gearbeitet hat und die Version 4 gesehen hat, wird mir recht geben, dass die Aktuelle Version (3.irgendwas) mit einem Sportwagen mit Slicks im Regen zu vergleichen ist. Das Teil schleudert und man verliert schnell den überblick und streift mal eine Leitplanke! XCode 4 hingegen, fühlt sich eher wie ein britischer Sportwagen mit einer angemessenen Bereifung an! Die nahtlos integrierten Versionierungs Hilfsmittel lassen jeden Entwickler entspannt arbeiten!