Zeiger und abgeleitete klassen

Ein Casting bringt nichts, weil es keine Sicherheit verspricht. Da kannste auch gleich diie Warning ausschalten.

Ich weiß nicht, was ihr alle gegen PProtokolle habt. Dazu sind sie da!

Dochm, das macht er. Das fällt dann negativ auf, wenn eine Methode in irgendwelchen Klassen mehrfach definiert ist, etwa einmal mit retval und einmal ohne, also ohne dass du einen Fehler gemacht hast! Ich glaube, -setName: ist so ein Kandidat.

id wirklich nur dann benutzen, wenn es _irgendein_ Objekt ist.

Du gehst die Sache falsch an.

Nimm die Klasse Fahrzeug und implementiere da wie bisher den Typen (wenn du ihn überhaupt noch brauchst, dazu später mehr.)

Leite Auto und Motorrad davon ab. Also nicht als Instanzvariable, sondern als Subklasse. Dort kannst du dann Erweiterungen unterbringen. Das meinte ich mit Zwischenklasse.

Wenn der Fahrzeugtyp nur Motorrad oder Auto speichert, kannst du bei Fahrzeug auch ganz auf den Typen verzichten. Den erfährst du zur Laufzeit von der Subklasse mittels

BTW: Gemeinsame Eigenschaften beider Fahrzeugtypen gehören in die Klasse Fahrzeug, Leistung etwa.

Die Anzahl spielt dabei keine Rolle. Und es ist der eigentlich vorgesehen Weg!

Original von Tom9811
Ein Casting bringt nichts, weil es keine Sicherheit verspricht. Da kannste auch gleich diie Warning ausschalten.

Stimmt, Castings bringen nichts - insbesondere der DSDS-Mist

Naja, es ist schon ein Unterschied, ob ich an einer bestimmten Stelle einen Typecast vornehme, an der ich weiß, dass er korrekt ist oder ob ich die Warnungen generell abschalte. Das ist m.E. vollkommen sauberer Stil. Um sicher zu gehen, kann ich den Typecast in ein if ([x isKindOfClass: Y]) schachteln, dann kann es keine Laufzeitprobleme damit geben - oder ich kann einen id-Cast in ein if ([x respondsToSelector:Y]) schachteln, um Y aufzurufen. Und ich komme damit an Stellen weiter, in denen mir Kategorien auch nicht helfen - insb. dann, wenn es sich tatsächlich um heterogene Collections handelt. Kategorien sind toll, das ist unbestritten - aber die Testmöglichkeiten, die sie eröffnen, sind nunmal statisch.

Original von rml
also, ich habe mal die tests mit id unf NSView gemacht.

er führt das programm korrekt aus, warnt aber, dass es sein kann, dass es die funktionen nicht gibt.

Hast Du denn auch die Headerdateien Deiner Subklassen importiert? Ich habe so das Gefühl, dass Du das nicht gemacht hast.

Michael

Original von rml
also, ich habe mal die tests mit id unf NSView gemacht.

er führt das programm korrekt aus, warnt aber, dass es sein kann, dass es die funktionen nicht gibt.
alo unbrauchbar, da ich beim compilieren mit hunderten von warnungen bombardiert werde, auch wenn das programm funktioniert...

jetzt kommt der test mit der abgeleiteten klasse...

Die Warnungen sollten aber nur bei der Referenzierung über NSView kommen und nicht über id.

Wenn dies der Fall ist, dann wirst Du diese Warnungen mit Hilfe der abgeleiteten Klassen nicht los werden, da Dir die Methoden der abgeleiteten Klassen in der Basisklasse, über welche Du ja dann refernzieren willst, auch nicht bekannt sind.

Der Ansatz mit den abgeleiteten Klassen ist zwar der richtige Weg in Bezug auf OO, wird Dir bei dem Referzierungsproblem jedoch nicht wirklich helfen.

Original von rml
na, bei NSView kommt diese meldung:

/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:36: warning: 'NSView' may not respond to '-initialize'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:36: warning: (Messages without a matching method signature
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:37: warning: 'NSView' may not respond to '-SetContext'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:38: warning: 'NSView' may not respond to '-drawit'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:78: warning: 'NSView' may not respond to '-SetContext'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:79: warning: 'NSView' may not respond to '-drawit'

Jepp, weil die Methoden in NSView nicht definiert sind.

Original von rml
und bei id folgende warnung:

/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:34: warning: assignment from incompatible pointer type
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:35: warning: passing argument 1 of 'addSubview:' from incompatible pointer type
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:36: warning: invalid receiver type 'id*'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:37: warning: invalid receiver type 'id*'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:38: warning: invalid receiver type 'id*'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:78: warning: invalid receiver type 'id*'
/Users/rml/Desktop/Amanda3D/Interface/MainContentView.m:79: warning: invalid receiver type 'id*'

Sieht so aus, als würdest Du als Referenz id *bla verwenden. Bei id reicht jedoch id bla aus.

Das liegt daran, dass id bereits als Zeiger auf ein Objekt definiert ist. Wenn du id * verwendest bekommst du einen Zeiger auf einen Zeiger auf ein Objekt und der Zeiger versteht natürlich keine Messages.:D

Ich meinte freilich: In diesem Falle bringen Castings nichts. Ich wende sie ja auch zuweilen an, etwa bei Ableitungen von NSWindowController.

Aber was er will, ist schlechtes Design. Und Casting würde das nur "dumm verdecken".

Kategorien, die hier gerne angeführt werden, sind zu kurz: Sie versprechen die Erweiterung eines bestehenden Objektes. Hier geht es aber nicht darum, etwas bestehendes zu erweitern, sondern lediglich darum, einen Satz von Methoden sichherzustellen. Ob die Basis oder Erweiterung, ererbt oder selbst implemmentiert sind, spielt keine Rolle: Protokolle.

Aber in seinem Fallle lässt sich das sogar durch eine Superklasse lösen.

Wie kommt es nur, dass ich heute für das Buch über abstrakte Methoden und Klassen geschrieben habe. Ich habe das wirklich nicht bewusst gemacht!

Wieso sollten denn die Methoden in der Basisklasse nicht bekannt sein?

Original von Tom9811
Wieso sollten denn die Methoden in der Basisklasse nicht bekannt sein?

Naja, dies trifft sicherlich nicht für alle Methoden zu, da die Methoden, welche zur Basisklasse passen, also auch in allen abgeleiteten Klassen vorhanden sind, natürlich auch in der Basisklasse definiert sind und somit über eine Referenz dieser Basisklasse ansprechbar sind.

Da die abgeleiteten Klassen im allgemeinen eine Spezialisierung der Basisklasse darstellen, kann es dort natürlich Methoden geben, welche in den anderen Spezialisierungen nicht benötigt und daher auch nicht vorhanden sind.

In der spezialisierten Klasse Auto könnte es z.B. eine Methode oeffneFahrerTuer geben, welche in der spezialisierten Klasse Motorrad natürlich keinen Sinn mach, wenn man mal von einem Standard Motorrad ohne Türen ausgeht. =) Ich würde daher nie auf die Idee kommen die Methode oeffneFahrerTuer in der gemeinsamen Basisklasse zu definieren, da man diese Methode in der Spezialisierung für Motorad einfach nicht benötigt. Diese Methode hätte dort keinen Inhalt ausser vielleicht eine Fehlermeldung zu produzieren, dass dieses Motorad keine Fahrertür hat.

Von daher wird rml die Warnungen also auch nicht los werden, wenn er z.B. versucht die Methode oeffneFahrerTuer über eine Referenz auf die Basisklasse anzusprechen. Damit der Compiler keine Warnungen mehr ausspuckt hilft nur eine Typumwandlung (cast) auf die spezialisiert Klasse, also hier z.B. auf Auto, oder die Änderung der Referenzierung, also die Verwendung einer Referenz auf die Klasse Auto. Die Verwendung von id als Referenzierungstyp ist natürlich auch immer möglich, allerdings wird dann natürlich überhaupt keine sinnvolle Methodenprüfung beim Compile mehr durchgeführt, da die verwendete Methode nur in einer beliebigen Klasse definiert sein muss, welche über den #import bekannt gemacht wurde, also z.B. in einer Klasse LKW, Bus, etc.

Hm, ich hoffe nur, dass rml jetzt nicht ganz verwirrt ist.