(Objc-C) Frage zu init...

tbo007

Empire
Registriert
06.02.05
Beiträge
86
]Hallo,

ich lerne momentan Objective C und habe eine Frage:

In vielen Programmen sieht man das folgende Konstrukt in der init Methode. Wofür ist das gut ? Der generelle Sinn der init Methode ist mir klar.
Mir geht es um den if-Block.

Code:
- (id)init { 
      if ((self = [super init])) { 
      // init Code...
      } 
      return self; 
}


Vielen Dank
 

Nighthawk

Linsenhofener Sämling
Registriert
16.12.06
Beiträge
2.558
Das überprüft, ob die Initialisierung der Super-Klasse (von der geerbt wurde) erfolgreich war.
 

Peter Maurer

Pommerscher Krummstiel
Registriert
16.03.04
Beiträge
3.077
Und: "self" wird auf den neuesten Stand gebracht. [super init] kann naemlich nicht nur "nil" zurueckgeben, manchmal bekommt man auch eine andere Instanz zurueck als die, die man reingesteckt hat.
 

tbo007

Empire
Registriert
06.02.05
Beiträge
86
Vielen Dank soweit.

Deine Antwort bringt mich direkt zu meiner nächsten Frage:

... manchmal bekommt man auch eine andere Instanz zurueck als die, die man reingesteckt hat.

Ich bin hauptberuflich Java-Entwickler und soweit ich Objective-C verstehe, gibt es ja Polymorphie über die Vererbungshierarchie einer Klasse hinaus.

Wird das nicht bei größeren Projekten äußerst gruselig?

Des weiteren habe ich noch eine Frage:
Ich sehe häufiger, dass bei Interface Deklerationen Klassen in spitzen Klammern hinter der Superklasse angegeben werden. ich konnte leider nicht den Sinn herausfinden, denn das Programm funktioniert auch ohne diese Angaben

Code:
@interface AppDelegate : NSObject [B]<UIApplicationDelegate>[/B]

Vielen Dank
 

Peter Maurer

Pommerscher Krummstiel
Registriert
16.03.04
Beiträge
3.077
Ich bin hauptberuflich Java-Entwickler und soweit ich Objective-C verstehe, gibt es ja Polymorphie über die Vererbungshierarchie einer Klasse hinaus.

Wird das nicht bei größeren Projekten äußerst gruselig?
Die Frage ist so allgemein formuliert, ich kann sie nur als Geschmacksfrage beantworten. Und mein Geschmack sagt: Nein. Nicht gruselig, sondern praktisch.

Ich sehe häufiger, dass bei Interface Deklerationen Klassen in spitzen Klammern hinter der Superklasse angegeben werden. ich konnte leider nicht den Sinn herausfinden, denn das Programm funktioniert auch ohne diese Angaben

Code:
@interface AppDelegate : NSObject [B]<UIApplicationDelegate>[/B]
In diesem Fall ist UIApplicationDelegate keine Klasse, sondern ein Protokoll, und das hat tatsaechlich was mit der o.g. hierarchieuebergreifenden Polymorphie zu tun. Und weil alle NSObject-Zeiger gleich sind, kann man das weglassen. Man schreibt es aber trotzdem gerne hin, denn dann freut sich u.a. der Compiler -- und die Lesbarkeit, die bei Objective-C m.E. ohnehin sehr im Vordergrund steht.
 

tbo007

Empire
Registriert
06.02.05
Beiträge
86
Super danke. Bei soviel Kompetenz hier im Forum macht das Lernen gleich mehr Spass.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.057
Die Frage ist so allgemein formuliert, ich kann sie nur als Geschmacksfrage beantworten. Und mein Geschmack sagt: Nein. Nicht gruselig, sondern praktisch.
Das Konzept war so "praktisch", daß man Protokolle eingeführt hat. Also auch die Objective-C Veranwortlichen haben die Notwendigkeit von expliziten Interfaces gesehen. Objective-C kannte bis dahin nur implizite Interfaces.
 

below

Purpurroter Cousinot
Registriert
08.10.06
Beiträge
2.858
Das Konzept war so "praktisch", daß man Protokolle eingeführt hat. Also auch die Objective-C Veranwortlichen haben die Notwendigkeit von expliziten Interfaces gesehen. Objective-C kannte bis dahin nur implizite Interfaces.

Das wird jetzt etwas off-topic, aber ich würde gerne meine Begriffskenntniss überprüfen.

Meinst Du, die Einführung das @protocol Keywords, oder der @required und @optional Keywords in Objective-C 2.0 ?

Alex
 

Peter Maurer

Pommerscher Krummstiel
Registriert
16.03.04
Beiträge
3.077
Jetzt steh' ich auf dem Schlauch:

Das Konzept war so "praktisch", daß man Protokolle eingeführt hat. Also auch die Objective-C Veranwortlichen haben die Notwendigkeit von expliziten Interfaces gesehen. Objective-C kannte bis dahin nur implizite Interfaces.
Die Anfuehrungszeichen lassen vermuten, dass Du es nicht praktisch findest. Warum? Oder nicht?

Und dass Protokolle fuer diese Zwecke nuetzlich sind, ist in diesem Thread ja auch schon erwaehnt. Es gibt sie, ehrlich gesagt, auch schon laenger als ich Jungspund mich mit Objective-C auseinandersetze. Deshalb waer' ich nicht auf den Gedanken gekommen, Objective-C-Polymorphie und Protokolle getrennt zu betrachten.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.057
Die Anfuehrungszeichen lassen vermuten, dass Du es nicht praktisch findest. Warum?
Ich sehe hier eine Diskrepanz zwischen dem Wort "praktisch" und der Existenz von Protokollen. Smalltalk lebt von der Idee, daß man keine expliziten Interfaces (Protokolle) braucht, da man bedingt durch das dynamische Dispatching ohne auskommt. Es gibt keine expliziten Interfaces, weil man der Meinung ist, daß man per Rapid Prototyping und Unit Testing die Sache schneller und besser erledigen könnte. Anforderung an Objekte werden somit nur implizit durch die jeweiligen Methodenaufrufe definiert.

Der andere Standpunkt ist der, daß man Anforderungen an Objekte durch explizite Interfaces festlegt. Je nach Programmiersprache gibt es unterschiedliche Konstrukte, um dies zu gewährleisten. Protokolle in Objective-C sind so eine Methode. Genauer betrachtet sind Protokolle Mehrfachvererbung für Arme, da es ganz ähnliche Einschränkungen wie bei einer Mehrfachvererbung ohne Konfliktlösungsmittel gibt, aber man keine Polymorphie über diesen Weg umsetzen kann. Das heißt, man kann keine Methodenimplementationen vorgeben etc. pp., eben all das was Polymorphie in einer Vererbungshierarchie auszeichnet.

Mögliche Probleme bei der Mehrfachvererbung sind:
  1. Kollision von Methodenbezeichnern
  2. Kollision von Attributbezeichnern
  3. Kompliziertes statisches Dispatching notwendig

Wenn man dies mit Objective-C Protokollen vergleicht, dann fällt auf das Punkt 3 wegen des dynamisches Dispatchings eh kein Thema ist und Punkt zwei entfällt, da man keine Methoden erlaubt hat. Punkt 1 muß man manuell einhalten, es gibt keine Möglichkeit Konflikte aufzulösen wie in anderen Sprachen. Es bleibt festzuhalten Protokolle sind eine Technik dem Nutzer einer Klasse zu signalisieren, daß einen konkrete Klasse über einen Satz von Methoden verfügt. Dies bleibt aber hinter den Möglichkeiten von Mehrfachvererbung zurück.

Kommen wir zum Punkt wie man Programme mit beiden Techniken umsetzt.
Wenn man eine Methode schreibt, die als Argument ein Objekt übergeben bekommt, dann verlangt man nun von diesem Objekt, daß es bestimmte Kontrakte einhält, unter anderem bestimmte Interfaces zur Verfügung stellt, da der eigene Programmcode sich darauf verläßt. Man kann dies je nach Programmiersprache nun direkt bei der Parameterübergabe sicherstellen (Objekt ist von Typ X, Objekt erfüllt Protokoll X o.ä.) oder man macht dies implizit in dem man einfach im Programmcode erwartet, daß sich das Objekt wie ein Objekt des Typs X verhält.

Die große Frage ist nun wie man das am besten gewährleistet, so daß man dies auch in einem größeren Team noch gut umsetzen kann, oder nach Jahren selbst noch sieht, was man da eigentlich erwartet hat. Die explizite Formulierung hat den Vorteil, daß man direkt sieht was man vom Objekt erwartet. Wenn man verschiedene Methoden eines Objekts nacheinander aufruft ist dies nicht leicht zu erkennen.

Persönliche Wertung der Sache
Meiner Meinung nach hätte man in Objective-C Mehrfachvererbung einbauen sollen, der Mehraufwand in der Programmiersprache ist gering, weil man es mit einer dynamisch dispatchen Sprache zu tun hat ist es sogar relativ einfach umzusetzen. Protokolle sind eine weniger leistungsfähige Möglichkeit, die aber absolut notwendig sind, so daß man Eigenschaften von Objekten über einen Sprachmechanismus zusichern kann. Da ich schon Erfahrung mit Programmiersprachen mit Mehrfachvererbung habe, kann ich nur sagen, daß es unsinnig ist aus ziemlich fadenscheinigen Gründen darauf zu verzichten.

Desweiteren teile ich Deine Meinung nicht, daß die Möglichkeit ohne Protokoll oder Klassenzugehörigkeit eine Methode aufzurufen was tolles sei. Man verschleppt so Fehler und macht die Fehlersuche komplizierter und deutlich teurer. Aber dies ist der grundsätzliche Unterschied zwischen stark typisierten Programmiersprachen und schwach typisierten Programmsprachen.
 

tjp

Altgelds Küchenapfel
Registriert
07.07.04
Beiträge
4.057
Meinst Du, die Einführung das @protocol Keywords, oder der @required und @optional Keywords in Objective-C 2.0 ?
Ich bezog mich darauf, daß man gegenüber SmallTalk Protokolle (@protocol) eingeführt hat.
 

below

Purpurroter Cousinot
Registriert
08.10.06
Beiträge
2.858
Ich bezog mich darauf, daß man gegenüber SmallTalk Protokolle (@protocol) eingeführt hat.

Danke, das habe ich mir beim lesen der langen Antwort (danke, war interessant) für Peter schon gedacht ;)

Alex
 

Peter Maurer

Pommerscher Krummstiel
Registriert
16.03.04
Beiträge
3.077
Vielen Dank, tjp!

Es haengt wohl ein bisschen von den eigenen Erfahrungen ab; und ich kann nur sagen, dass ich schon oft froh ueber diese unspezifischen Aufrufe war -- nur zwei Beispiele:

1. Sowohl NSButtons (bzw. deren Zellen) als auch NSMenuItems haben eine Status-Eigenschaft, die durch NSOnState et al. beschrieben wird. Die von Dir ungeliebte Beliebigkeit der Aufrufe laesst mich davon ausgehend nun ganz einfach NSObject-Kategorie-Methoden erstellen, die fuer NSButtons und NSMenuItems funktionieren. Das Fehlerverschlepprisiko halte ich persoenlich dabei fuer beherrschbar. Mir ist das jedenfalls noch nie um die Ohren geflogen.

2. NSSet, NSArray und NSDictionary verstehen die Botschaft objectEnumerator. Und tatsaechlich ist es in manchen Code-Teilbereichen unerheblich, ob ich es mit dem einen oder anderen zu tun habe -- also sende ich ein [(id)arrayOrDictionary objectEnumerator] und spare Zeit, weil ich die konkreten Spezialfaelle nicht getrennt behandeln muss. Ausserdem muss ich mich so nicht aergern, dass es keine gemeinsame Superklasse (z.B. etwas NSSet-aehnliches) gibt. Es geht ja auch so.

Natuerlich liessen sich solche Sachen hypothetisch eleganter loesen -- z.B. durch die von Dir genannte mehrfache Vererbung. Aber ausgehend von dem, was Objective-C und Cocoa derzeit hergeben, bin ich von den geschilderten Moeglichkeiten im Sinne eines halbvollen Glases ganz angetan. :)
 

Amin Negm-Awad

Süsser Pfaffenapfel
Registriert
01.03.07
Beiträge
665
Das Konzept war so "praktisch", daß man Protokolle eingeführt hat. Also auch die Objective-C Veranwortlichen haben die Notwendigkeit von expliziten Interfaces gesehen. Objective-C kannte bis dahin nur implizite Interfaces.
Ich weiß schon nicht, was du mit "eingeführt" hat meinst. Aber beide Dinge stehen nebeneinander und haben verschiedene Aufgabengebiete.

Darüber hinaus sind auch nicht Protokolle "Mehrfachvererbung für Arme". Vererbung bezieht sich immer auch auf eine potentielle Implementierung. Das ist keine INterfacebeschreibung wie Protokolle, sondern ein Funktionalitätsimport.

Richtig ist, dass man in anderen Programmiersprachen pVC verwenden kann, kastrierte Klassen, die dann über das Konstrukt der Mehrfachvererbung letztlich dasselbe leisten können, wenn man mal über die dann wiederum notwendige Konstruktion von Namespaces die schlimmsten Auswüchse heilt.

Protokolle sind also etwas, wofür man in anderen Programmiersprachen die Kastration eines Systems benötigt, um dann über eine weitere Konstruktion der Mehrfachvererbung etwas hinzubekommen, was man dann mit noch einer Konstruktion erträglich macht.

Oder kurz: Praktisch.