Subclassing vermeiden mittels Blocks?

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

  • Subclassing vermeiden mittels Blocks?

    Hi Leute, mal wieder eine Designfrage an Euch: Derzeit arbeite ich an einer generischen UI-Komponente, die regen Gebrauch von CALayer macht. Um die accessibility-Unterstützung muss ich mich dafür selber kümmern und habe mir eine helper-Klasse geschrieben, welche das NSAccessibility Protokoll implementiert und in jedem Layer gespeichert wird (mittels der KVC-Container Erweiterung von CALayer). Da ich diverse Layertypen unterstütze und keine parallele Klassenhierarchie (CALayer <-> AccessibilityHelper) pflegen möchte, übergebe ich der Helperklasse bei der layer-erzeugung passende Blocks (properties der Helperklasse), welche eine kontextspezifische Anpassung ermöglichen. Somit habe ich nur die generische Helperklasse, welche für alle Layertypen anpassbar (CALayer, CAScrollLayer etc) ist. Vor der Verfügbarkeit von Blocks hätte ich das mit Subklassen der Helperklasse gemacht. Der kontextspezifische Code wandert also von den Klassen mittels Blocks in die Attribute der Klasse. Würdet ihr so etwas machen oder ist das ein antipattern? Danke für Eure Zeit, Markus

  • Im "modernen" C++ ist das haeufig, also dass man Funktoren uebergibt um Dinge ohne Subclassing genauer zu spezifizieren. Ein wenig wie Delegates. Ich benutze das auch selber sehr gerne. Praktisches Beispiel waere eine allgemein gehaltene TCP Server Klasse, etwa ein HTTP Server. Anstelle diese zu subclassen kann ich auch einfach externe Methoden um auf GET oder POST zu reagieren dranhaengen (hier boost::signals2/boost::bind). Ich nehme dafuer zwar keine Blocks (bzw. eins der C++ Aequivalente), aber das ist ja egal.

    Oder vielleicht ein Beispiel mehr in Deine Richtung: Ein OpenGL Zeichenfunktion, die ich an verschiedene Dinge haengen kann und etwa vor jedem SwapBuffer zusaetzlich aufgerufen wird. So kann ich ein "Mach ein roten Rahmen drumrum" an was auch immer haengen - sofern das was-auch-immer darauf ausgelegt ist. Dadurch muss ich nicht alles Ableiten als MachWasMitRotemRahmen und bin bei der RoteRahmen funktion auch recht flexibel.
    ♥C++

  • Das hört sich für mich so an, als wenn Du Deine Komponente unterschiedlich zusammenstecken kannst. Da kommst Du mit Vererbung schnell in eine Sackgasse und so kann Dein Ansatz ein guter Lösungsweg sein. Ich würde darauf achten, eine möglichst einheitliche Schnittstelle für die verschiedenen Operationen bereitzustellen, aber dafür kenne ich mich mit Accessibility zu wenig aus.
    „Meine Komplikation hatte eine Komplikation.“

  • Ich habe zwar auch nichts dagegen einzuwenden und weiß auch nicht genau, ob ich das richtig verstanden habe. Aber was spricht gegen Delegates? Dann hast du Ivars in deiner "Helperfunktionalität". Blocks sind ja immer ein bisschen einsam.
    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"?

  • Zuallererst vielen Dank für Eure Antworten!

    Vielleicht noch kurz was zum Problem. Im wesentlichen geht es um folgende Methoden des NSAccessibility Protocols:

    Quellcode

    1. // im Helper, getHandler und setHandler sind die block-properties
    2. - (id)accessibilityAttributeValue:(NSString *)attribute
    3. {
    4. if ( self.getHandler ) {
    5. return self.getHandler( attribute );
    6. }
    8. - (void)accessibilitySetValue:(id)value forAttribute:(NSString *)attribute
    9. {
    10. if ( self.setHandler ) {
    11. self.setHandler( value, attribute );
    12. }
    13. }
    Alles anzeigen

    Es besteht eine 1:1 Zuordnung zwischen Layer und Helper, mit delegation würde sich das umgebende view anbieten, aber da hätte müsste ich dann alle Layer unterscheiden und hätte lange if/else-Ketten. Die beiden genannten Methoden benötigen Interna des jeweiligen Layers bzw. hostenden views (z.Bsp. den Titel des angezeigten Bildes in einem CALayer, oder die sichtbaren Layer in einem CAScrollLayer oder die aktuelle Selektion), mit Blocks lässt sich das natürlich im jeweiligen Kontext gut bereitstellen.

    Naja, nochmals Danke für Eure Anmerkungen, hat geholfen, die Betriebsblindheit etwas zu lichten...

  • Ja, das ist kein Problem von Delegation an sich. Ich bezog mich auf den Fall, dass das umgebende View das Delegate für alle Helper-Instanzen ist (was sich anbieten würde, da es das benötigte Wissen hat). Ich ging von einer einzigen delegate-Methode aus, dann müsste ich in dieser die entspr. Layer unterscheiden. Um das zu vermeiden müsste man dann wohl ein entspr Protokoll entwerfen und die Unterscheidung im Helper machen oder aber entspr Delegates pflegen. Genau das will ich jedoch nicht. Es handelt sich beim Helper um eine interne Klasse, die der Benutzer überhaupt nicht zu Gesicht bekommt (der arbeitet nur mit dem view). Das Problem ist eine wiederverwendbare generische Lösung um CALayer (und alle Subklassen) NSAccessibility-konform zu machen.