Zeiger und abgeleitete klassen

  • Zeiger und abgeleitete klassen

    sagt mal.
    mal angenommen, ich habe einen ganzen haufen, recht umfangreiche klassen erstellt, die allesamt von nsview abgeleitet sind.

    wenn ich nun irgendwo im programm einen zeiger haben möchte, der eine der vielen verschiedenen klassen aufnehmen soll, reicht das, wenn ich hier ein NSView *blah nehme und hier irgedeines meiner objekte einfüge, obwohl diese erheblich unterschiedlich sind ?

    ich hoffe, ich konnte halbwegs erklären, was ich meine ...

  • RE: Zeiger und abgeleitete klassen

    Ich habe das zwar nicht so ganz verstanden. Aber du hast dann das Problem, dass NSVieiw deine Methoden mutmaßlich nicht kennt. Hilfe schaffen hier entweder Protokolle oder aber eine "Zwischenklasse".
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • ich versuchs mal anders:

    @interface MCVContainertyp1 : NSView { .... blah ohne ende variablen und funktionen}

    @interface MCVContainertyp2 : NSView { .... hier auch alles mögliche}

    NSView *Zwischenspeicher;



    Zwischenspeicher = z.b. zeiger auf MCVContainertyp1 oder MCVContainertyp2 oder .... ;

    der typ der unter blah gespeichert ist, ist bekannt! daher weiss ich auch, welche funktionen ich jeweils aufrufen kann und welche nicht.

    blah muss aber alle arten dieser containertypen aufnehmen können.


    *ähm* jetzt besser ?

  • Original von gritsch
    Original von bbert
    Ja es ist möglich, aber ich würde in so einen Fall "id" verwenden, da der Compiler sonst meckert.


    warum sollte er maulen?

    Tut er hier ja auch nicht (außer dass view bei mir unused ist...)

    NSView *view = [[NSImageView alloc] initWithFrame:NSMakeRect(0,0,10,10)];


    bzw hier mault er auch net:

    id nix = nil;
    NSView *view = [nix enclosingScrollView];

  • Original von gritsch
    warum sollte er maulen?

    Tut er hier ja auch nicht (außer dass view bei mir unused ist...)

    NSView *view = [[NSImageView alloc] initWithFrame:NSMakeRect(0,0,10,10)];

    Bei der Zuweisung mault er noch nicht. Aber wenn Du dann zum Beispiel

    Quellcode

    1. [view setImageFrameStyle:NSImageFrameButton];
    machst, geht das Gemaule los.

    Michael

  • Original von Michael
    Original von gritsch
    warum sollte er maulen?

    Tut er hier ja auch nicht (außer dass view bei mir unused ist...)

    NSView *view = [[NSImageView alloc] initWithFrame:NSMakeRect(0,0,10,10)];

    Bei der Zuweisung mault er noch nicht. Aber wenn Du dann zum Beispiel

    Quellcode

    1. [view setImageFrameStyle:NSImageFrameButton];
    machst, geht das Gemaule los.

    Michael


    klar, das war jetzt nur ein beispiel dass er beim zuweisen nciht mault! Er weis ja welche methoden seine Klassen kennen und kann die dann einfach in ein NSView-Additions-Interface packen.

    NSView *view = irgendwas; Da mault er wenn du aus versehen nen string oder sowas zuweist. Bei id view = irgendwas; aber nicht...

  • Original von gritsch
    klar, das war jetzt nur ein beispiel dass er beim zuweisen nciht mault! Er weis ja welche methoden seine Klassen kennen und kann die dann einfach in ein NSView-Additions-Interface packen.

    Das finde ich ein wenig von hinten durch die Brust ins Auge. Umständlicher geht's nicht. Den Nutzwert davon würde ich auch nicht sehr hoch einschätzen.

    Michael

  • Original von bbert
    Ja klar, weil der Compiler bei id ja auch nicht überprüfen kann auf welche Messages das Object antwortet.

    Auch bei id prüft der Compiler, ob es die Methode überhaupt gibt. Er guckt dabei aber in allen Klassen nach, die ihm in der Übersetzungseinheit durch #import bekannt gemacht sind.

    Michael

  • Auch bei id prüft der Compiler, ob es die Methode überhaupt gibt. Er guckt dabei aber in allen Klassen nach, die ihm in der Übersetzungseinheit durch #import bekannt gemacht sind.

    Oh, das wußte ich nicht ich dachte immer er würde es dann überhaupt nicht überprüfen.

    Bert

  • Ich möchte ja nicht meckern, aber wegen all dieser Probleme schräbte ich bereits, dass man tunlichst eine Zwischenklasse einzieht oder ein Protokoll festlegt, wenn erstes nicht geht.

    Ansonsten ist es genauer und weniger fehleranfällig, wenn man so weit wie mögllich typisiert, also NSView als Klasse verwendet. Die zahlreichen Vorteile hat ja bereits gritsch genannt.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Und es ist gut, dass er mault! Wird diese Methode etwa nur bei bestimmten Bedingungen ausgeführt, fällt der Aurfuf möglicherweise beim Debuggen durch. Der Fehler taucht dann beim Anwender auf.

    Das Gemaule schaltet man tunlichst nicht durch id, sondern durch Protokolle ab. Dafür sind sie schließlich da.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Oder aber durch einen Typecast. rml schreibt ja, dass er weiss, welche Objekte er hat. Dann mann man im Methodenaufruf auch schlicht angeben, um was für ein Objekt es sich konkret handelt.

    Wenn sich die Objekte sinnvoll gruppieren lassen, sind Oberklassen m.E. die erste Wahl. Wenn sie eigentlich grundverschieden sind und nur syntaktisch gleiche Methoden haben, ist eher ein Protokoll angebracht. Sonst landet man bei dem Quatsch, der z.B. bei Java herrscht: Hierarchien, die nicht durch ihre semantische Klassifikation, sondern durch ihre syntaktischen Methoden definiert sind - "Throwable", "Drawable" usw. - ich kann mir beim besten Willen nicht vorstellen, dass das die ursprüngliche Intention der OO war...
    Multigrad - 360°-Produktfotografie für den Mac