Wofür braucht man noch properties?

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Wofür braucht man noch properties?

    Hi,
    der Titel sagts schon. Ich verstehe seit arc mittlerweile nicht mehr, wofür man properties (im Sinne von accessoren) überhaupt noch braucht. Eine reine iVar mit geeignetem reference prefix müsste doch reichen.
    Besonders bei hauptsächlich privat gebrauchten Variablen braucht man unterm Strich dann doch erheblich weniger Code.
    Wer kann mir erklären, warum Apple templates immer noch properties benutzen? Werden die doch noch für die Speicherverwaltung gebraucht?
  • Descartes schrieb:

    Hi,
    der Titel sagts schon. Ich verstehe seit arc mittlerweile nicht mehr, wofür man properties (im Sinne von accessoren) überhaupt noch braucht. Eine reine iVar mit geeignetem reference prefix müsste doch reichen.
    Besonders bei hauptsächlich privat gebrauchten Variablen braucht man unterm Strich dann doch erheblich weniger Code.
    Wer kann mir erklären, warum Apple templates immer noch properties benutzen? Werden die doch noch für die Speicherverwaltung gebraucht?

    Jein.

    Der Nichtgebrauch von Accessoren kann zu Fehlern bei der Speicherverwaltung führen. Ein weiterer Grund ist jedoch die Kapselung. Du hast über Accessoren eine feste Schnittstelle. Dazu kommt, dass du bei Property copy oder retain (strong) wählen kannst.

    Der wahre Grund ist aber etwas anderes. Von außen sollte nie auf Ivars zugegriffen werden. (Ausnahmen bleiben hier Ausnahmen.) Also brauchst du für den Zugriff von außen ohnehin @property (oder eigene Deklaratoren, was mehr Aufwand ist). Wenn jedoch von außen nicht auf die Ivars zugegriffen wird, dann müssen sie auch nicht im header stehen. Ergo: Über Propertys synthetisieren. Hierher gehört auch, dass umgekehrt Propertys eine Information nach außen sichtbar machen, die nach außen gehört: copy oder nicht. Das ist ja für den Anwender der Klasse wichtig.

    Das Ganze ist durch zwei Neuerungen (die zweite wird gerne vergessen, auch in der Fachliteratur) etwas weg bei internen Ivars:

    1. Du kannst Ivars nun auch in der Implementierung definieren. Der Grund für den Verzicht auf eine Definition fällt also bei internen Ivars nun weg.

    2. ARC, wie du selbst sagst.

    Nichtsdestotrotz bleibt es aber dabei, dass du die Kapselung und zusätzliche Information hast. Es gibt Leute, die sagen, dass das intern eine nur untergeordnete Rolle spielt, da ich diese Information ja ohnehin habe. Spätestens beim Ableiten ist das aber so eine Sache. Aber man kann auch verzichten. Manche sagen das.
    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"?
  • Hallo Amin. Einige Punkte deiner Antwort kann ich nicht ganz nachvollziehen.
    Ein weiterer Grund ist jedoch die Kapselung
    Die accessoren haben Mangels stringenter Kapselung von Methoden in Objective-C die Kapselung der iVars doch erst verkrüppelt. Wenn ich nur mit iVars arbeite, kann ich diese fein säuberlich mit @private, @protected und @public kapseln und muss nicht erst eine Kategorie für protected Properties erstellen (private ist, wenn ich mich nicht ganz irre, mit properties erst gar nicht möglich).
    Von außen sollte nie auf Ivars zugegriffen werden
    Hast du dazu eine Quelle?

    Du kannst Ivars nun auch in der Implementierung definieren.
    Wie macht man das? Eine Instanz-Variable sollte keinen Class-Scope haben.

    Der Nichtgebrauch von Accessoren kann zu Fehlern bei der Speicherverwaltung führen.
    Kannst du diese Phrase mit Inhalt füllen, wenn wir von einer ARC Umgebung sprechen?

    Recht gebe ich dir aber darin, dass Accessoren in Spezialfällen nach wie vor eine Existenzberechtigung haben (copy, multithreading Verhalten, ...).
    Ich frage mich nur, ob ich später gehörig auf die Nase falle, wenn ich jetzt in einem größeren Projekt künftig größtenteils nur noch iVars benutze :?:
    Wie viel Code ich alleine schon für jedes IBOutlet sparen könnte :D
  • Descartes schrieb:

    Hallo Amin. Einige Punkte deiner Antwort kann ich nicht ganz nachvollziehen.
    Ein weiterer Grund ist jedoch die Kapselung
    Die accessoren haben Mangels stringenter Kapselung von Methoden in Objective-C die Kapselung der iVars doch erst verkrüppelt. Wenn ich nur mit iVars arbeite, kann ich diese fein säuberlich mit @private, @protected und @public kapseln und muss nicht erst eine Kategorie für protected Properties erstellen (private ist, wenn ich mich nicht ganz irre, mit properties erst gar nicht möglich).
    Von außen sollte nie auf Ivars zugegriffen werden
    Hast du dazu eine Quelle?

    Du kannst Ivars nun auch in der Implementierung definieren.
    Wie macht man das? Eine Instanz-Variable sollte keinen Class-Scope haben.

    Der Nichtgebrauch von Accessoren kann zu Fehlern bei der Speicherverwaltung führen.
    Kannst du diese Phrase mit Inhalt füllen, wenn wir von einer ARC Umgebung sprechen?

    Recht gebe ich dir aber darin, dass Accessoren in Spezialfällen nach wie vor eine Existenzberechtigung haben (copy, multithreading Verhalten, ...).
    Ich frage mich nur, ob ich später gehörig auf die Nase falle, wenn ich jetzt in einem größeren Projekt künftig größtenteils nur noch iVars benutze :?:
    Wie viel Code ich alleine schon für jedes IBOutlet sparen könnte :D

    Zusammengefasst: Du hast keine Ahnung von Objective-C und Cocoa. Bereits Einleitungen zeigen dir die Problematik. Du kannst es aber einfach machen. Aus Fehlern lernt man ja.
    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"?