Alle Methoden einer Klasse virtual vs nur manche

[kaiserludi]

Ausgangslage: Eine Klasse, welche als Basisklasse für andere dienen soll und in der einige Methoden zwingend virtual sein müssen, damit die Klasse ihre Funktionalität erfüllen kann. Sonderlich performance kritisch ist sie nicht.

Wie nun die restlichen Methoden implementieren? Einfach pauschal alle virtual oder nur diejenigen, bei denen es sinnvolle Anwendungsfälle, um sie zu überschreiben, zu geben scheint, und bei den anderen auf virtual verzichten und ein wenig Performance sparen, mit dem Risiko, dass vielleicht doch irgendwer einen Anwendungsfall findet, wo er sie überschrieben will.

Insbesondere getter kommen mir da ein den Sinn. Bei solchen Minimethoden wie getFoo(void){return mFoo;} ist der Overhead beim Aufruf durch virtual ja schon durch relevant im Vergleich zur Ausführungszeit des eigentliches Codes und solche getter tendieren auch oft dazu, relativ häufig aufgerufen zu werden, aber womöglich braucht eine Subklasse doch eine Funktionalität wie z.B. getFoo(void){debugPrintToLog("foo has been accessed"); return mFoo;} und wenn der Compiler eindeutig sieht, dass auf jeden Fall die Originalmethode aufgerufen wird und keine Subklassenimplementation, dann kann er ja auch inlinen und es ist keine Laufzeitoverhead durch virtual mehr da.

[dot]

Pauschal alles virtual ist imo keine gute Idee.
Methoden macht man virtual wenn das System erwartet dass die Methode überschrieben wird und nicht weil ein Benutzer des Systems vielleicht auf die Idee kommen könnte es zu tun ;)

Getter sollte man sowieso eher vermeiden. Wenn du Getter hast die ständig überall aufgerufen werden, dann würd ich mal das Design an sich hinterfragen.

[kaiserludi]

Wenn eine Methode überschrieben werden MUSS, dann macht man sie pure virtual, wenn sie hingegen virtual ist, dann ist das für mich ein Zeichen, dass man sie überschreiben KANN und die Klasse damit klar kommt, während man eine Methode, die nicht virtual ist, NICHT überschreiben DARF, ohne undefiniertes Verhalten zu riskieren.
Deswegen würde ich tendenziell sagen, lieber 10 virtual zu viel als 1 zu wenig.

Wie willst du ohne Getter Zugriffsrechte regeln?
Dank inline kann man sie, wenn es wirklich drauf ankommt, auch ohne Performanceverlust gegenüber Direktzugriff auf die Variabeln nutzen.
Ich sehe da nur Vorteile, keine Nachteile.

[Schrompf]

Schlicht halten: mach das virtual, was Du zum Überschreiben vorsiehst. Alles andere kann ja später noch von jemand Anderem virtual gemacht werden, wenn der das braucht. Code ist nicht in Stein gemeiselt.

Ich möchte bei manchen Sachen sicher gehen, dass sie nicht überschreiben werden. Daher mache ich die Methoden und Membervars davon dann private. Alles andere kann aber protected bleiben, ich sehe da keinen Grund, vorab irgendwas zu erzwingen.

[kaiserludi]

Bei library APIs ist es aber wünschenswert, spätere Änderungen, die sich durch weise Voraussicht vermeiden lassen, auch zu vermeiden - Thema Abwärtskompatibilität.
Als Nutzer einer vorkompilierten Lib ohne Sourcezugriff einfach mal ein virtual im Header davor zu schreiben, wenn man es braucht, ist auch keine gute Idee.

[Schrompf]

Von "Library API" stand aber nix im Ausgangsbeitrag. Außerdem nutzt niemand bei Verstand eine Lib, die er nur ohne Quelltext kriegen kann. Daher verfahre ich trotzdem so, wie ich das beschrieben habe, und empfehle das auch gern so weiter.

[dot]

Wenn eine Methode überschrieben werden MUSS, dann macht man sie pure virtual, wenn sie hingegen virtual ist, dann ist das für mich ein Zeichen, dass man sie überschreiben KANN und die Klasse damit klar kommt, während man eine Methode, die nicht virtual ist, NICHT überschreiben DARF, ohne undefiniertes Verhalten zu riskieren.
Deswegen würde ich tendenziell sagen, lieber 10 virtual zu viel als 1 zu wenig.

Ich versuche generell Basisklassen die keine puren Interfaces sind zu vermeiden.
Der Sinn von Vererbung ist nunmal Abstraktion und nicht Code Reuse.
Besonders wenn es um eine API geht, würd ich mich auf reine Interfaces beschränken.

Wie willst du ohne Getter Zugriffsrechte regeln?

Ich würde das System so designen dass es ohne irgendwelche "Zugriffe" auskommt ;)
Vielleicht ist das nicht immer möglich oder sinnvoll, aber meiner Erfahrung nach sehr viel öfter als man denkt.
Wenn du eine Klasse mit vielen Gettern hast, dann ist imo entweder am Design was faul oder der entsprechende Typ sollte einfach ein normales struct mit public Membern sein, weil du sowieso grad auf einer Ebene unterwegs bist wo pure OOP nichtmehr unbedingt sinnvoll ist.
OOP ist eben kein Allheilmittel...

[kaiserludi]

Von "Library API" stand aber nix im Ausgangsbeitrag. Außerdem nutzt niemand bei Verstand eine Lib, die er nur ohne Quelltext kriegen kann. Daher verfahre ich trotzdem so, wie ich das beschrieben habe, und empfehle das auch gern so weiter.

Demnach sind jegliche Nutzer der diversen propietären System Libraries von MS oder auch von Apple, wie. z.B. der WinAPI, DX, Cocoa, oder Cocoa Touch und damit wohl die große Mehrheit der Coder auf Windows, OS X oder iOS, nicht bei Verstand?
Aber selbst bei Open Source Libraries würde ich das auf keinen Fall so empfehlen, denn sobald du die Lib nicht über ihre public API nutzt, sondern ihr ihrem internen Code herumwuselst, hast du viel Spaß beim Mergen, wenn die mal ein wenig Refactoring machen, was gerade bei vielen OS-Libs durchaus nicht ganz selten der Fall ist.

Wie willst du ohne Getter Zugriffsrechte regeln?

Ich würde das System so designen dass es ohne irgendwelche "Zugriffe" auskommt ;)
Vielleicht ist das nicht immer möglich oder sinnvoll, aber meiner Erfahrung nach sehr viel öfter als man denkt.
Wenn du eine Klasse mit vielen Gettern hast, dann ist imo entweder am Design was faul oder der entsprechende Typ sollte einfach ein normales struct mit public Membern sein, weil du sowieso grad auf einer Ebene unterwegs bist wo pure OOP nichtmehr unbedingt sinnvoll ist.
OOP ist eben kein Allheilmittel...

Ein struct mit public Membern ermöglicht dann eben auch public write access und oft will man eben nach außen nur readonly access und nur für die Klasse selbst + eventuell Subklassen und/oder Freunde Writeaccess haben.
Ich habe hier z.B. einen Fall vorliegen, wo Änderungen an bestimmten Werten übers Netzwerk synchronisiert werden, das heißt, ich will vermeiden, dass jemand versehentlich einfach auf der Variable direkt herum schreibt. denn public direct access auf die Variable würde bedeuten, dass lokaler Wert und remote-Wert nicht mehr synchron sind.

[dot]

Ein struct mit public Membern ermöglicht dann eben auch public write access und oft will man eben nach außen nur readonly access und nur für die Klasse selbst + eventuell Subklassen und/oder Freunde Writeaccess haben.

Wie gesagt, man kann das Ding üblicherweise so designen dass es ohne Getter auskommt. Solch ein Design ist meiner Erfahrung nach meistens die bessere Variante.
Wenn abgeleitete Klassen drauf schreiben wollen, sollte der Member dann nicht eher in der abgeleiteten Klasse liegen?

Ich habe hier z.B. einen Fall vorliegen, wo Änderungen an bestimmten Werten übers Netzwerk synchronisiert werden, das heißt, ich will vermeiden, dass jemand versehentlich einfach auf der Variable direkt herum schreibt. denn public direct access auf die Variable würde bedeuten, dass lokaler Wert und remote-Wert nicht mehr synchron sind.

Wie wärs mit einem Callback wenn ein Wert sich ändert? Dann gibt deine Library nicht vor wie und ob die Daten gespeichert werden müssen...

[kaiserludi]

Ein struct mit public Membern ermöglicht dann eben auch public write access und oft will man eben nach außen nur readonly access und nur für die Klasse selbst + eventuell Subklassen und/oder Freunde Writeaccess haben.

Wie gesagt, man kann das Ding üblicherweise so designen dass es ohne Getter auskommt. Solch ein Design ist meiner Erfahrung nach meistens die bessere Variante.
Wenn abgeleitete Klassen drauf schreiben wollen, sollte der Member dann nicht eher in der abgeleiteten Klasse liegen?

Es geht mir darum, dass auf jeden Fall auch die Basisklasse drauf schreibt. Ob abgeleitete Klassen auch drauf schreiben können sollen, entscheidet dann nur noch darüber, ob die Variable in der Basisklasse protected oder private ist, public ist sie in beiden Fällen nicht, man braucht also für public read access dann eine Methode. Die Variable private in der abgeleiteten Klasse zu definieren macht nur Sinn ,wenn die basisklasse sie überhaupt nicht kennen braucht.

Ich habe hier z.B. einen Fall vorliegen, wo Änderungen an bestimmten Werten übers Netzwerk synchronisiert werden, das heißt, ich will vermeiden, dass jemand versehentlich einfach auf der Variable direkt herum schreibt. denn public direct access auf die Variable würde bedeuten, dass lokaler Wert und remote-Wert nicht mehr synchron sind.

Wie wärs mit einem Callback wenn ein Wert sich ändert? Dann gibt deine Library nicht vor wie und ob die Daten gespeichert werden müssen...

Wenn mich der momentane Wert x von Foo interessiert, dann finde ich es einfach schöner, wenn ich z.B. einfach if(mFoo.X == mFoo2.X) schreiben kann und nicht selbst mit tracken muss, welche Instanzen von Foo überhaupt existieren, in welcher Foobar-Instanz sie gerade sind, welche Foo-Instanz in welchen Strukturen bei mir wo gespeichert ist und ich will mich dann eben auch nicht darum kümmern müssen, alle Werte für alle Foo-Instanzen in Callbacks upzudaten, nur weil ich zu anderen Zeitpunkten als denen, zu denen die Updates eintreffen, an dem gerade aktuellen Wert interessiert bin. Dafür sorgen, dass lokal die aktuellsten Werte vorliegen, die zu bekommen sind, wenn ich sie gerade brauche, hat die Lib, dafür habe ich sie ja.
Ein CB ist ideal, wenn ich wissen will, wann sich der Wert ändert, nicht, wenn mich interessiert, wie der aktuelle Wert gerade ist.
Meine Devise ist da "So highlevel wie möglich, so lowlevel wie nötig" - Wenn es nicht nötig ist, dass der Nutzer die Werte selbst verwalten muss, dann kann ich es ihm auch abnehmen.

Ich muss aber auch dazu sagen, dass es sich bei dem ganzen um ein High-Level Framework hnadelt, welches on top auf ein low-level Framework aufsattelt und wer so etwas selbst verwalten will, der würde eh das low-level Framework nutzen

[dot]

Ein struct mit public Membern ermöglicht dann eben auch public write access und oft will man eben nach außen nur readonly access und nur für die Klasse selbst + eventuell Subklassen und/oder Freunde Writeaccess haben.

Wie gesagt, man kann das Ding üblicherweise so designen dass es ohne Getter auskommt. Solch ein Design ist meiner Erfahrung nach meistens die bessere Variante.
Wenn abgeleitete Klassen drauf schreiben wollen, sollte der Member dann nicht eher in der abgeleiteten Klasse liegen?

Es geht mir darum, dass auf jeden Fall auch die Basisklasse drauf schreibt. Ob abgeleitete Klassen auch drauf schreiben können sollen, entscheidet dann nur noch darüber, ob die Variable in der Basisklasse protected oder private ist, public ist sie in beiden Fällen nicht, man braucht also für public read access dann eine Methode. Die Variable private in der abgeleiteten Klasse zu definieren macht nur Sinn ,wenn die basisklasse sie überhaupt nicht kennen braucht.

Wenn du mich fragst hast du definitiv einen Fehler im Design wenn deine Basisklasse Member hat auf die sowohl die Basis als auch eine abgeleitete Klasse schreiben.
Auch eine protected Membervariable ist ungekapselter Zustand. Auch Getter/Setter ändern nix an der Tatsache dass du Implementierungsdetails nach außen trägst.

Ich habe hier z.B. einen Fall vorliegen, wo Änderungen an bestimmten Werten übers Netzwerk synchronisiert werden, das heißt, ich will vermeiden, dass jemand versehentlich einfach auf der Variable direkt herum schreibt. denn public direct access auf die Variable würde bedeuten, dass lokaler Wert und remote-Wert nicht mehr synchron sind.

Wie wärs mit einem Callback wenn ein Wert sich ändert? Dann gibt deine Library nicht vor wie und ob die Daten gespeichert werden müssen...

Wenn mich der momentane Wert x von Foo interessiert, dann finde ich es einfach schöner, wenn ich z.B. einfach if(mFoo.X == mFoo2.X) schreiben kann und nicht selbst mit tracken muss, welche Instanzen von Foo überhaupt existieren, in welcher Foobar-Instanz sie gerade sind, welche Foo-Instanz in welchen Strukturen bei mir wo gespeichert ist und ich will mich dann eben auch nicht darum kümmern müssen, alle Werte für alle Foo-Instanzen in Callbacks upzudaten, nur weil ich zu anderen Zeitpunkten als denen, zu denen die Updates eintreffen, an dem gerade aktuellen Wert interessiert bin. Dafür sorgen, dass lokal die aktuellsten Werte vorliegen, die zu bekommen sind, wenn ich sie gerade brauche, hat die Lib, dafür habe ich sie ja.

D.h. deine Library gibt mir vor dass es Foo gibt die Werte x haben und die Foobar Instanzen gehören?

[kaiserludi]

Ein struct mit public Membern ermöglicht dann eben auch public write access und oft will man eben nach außen nur readonly access und nur für die Klasse selbst + eventuell Subklassen und/oder Freunde Writeaccess haben.

Wie gesagt, man kann das Ding üblicherweise so designen dass es ohne Getter auskommt. Solch ein Design ist meiner Erfahrung nach meistens die bessere Variante.
Wenn abgeleitete Klassen drauf schreiben wollen, sollte der Member dann nicht eher in der abgeleiteten Klasse liegen?

Es geht mir darum, dass auf jeden Fall auch die Basisklasse drauf schreibt. Ob abgeleitete Klassen auch drauf schreiben können sollen, entscheidet dann nur noch darüber, ob die Variable in der Basisklasse protected oder private ist, public ist sie in beiden Fällen nicht, man braucht also für public read access dann eine Methode. Die Variable private in der abgeleiteten Klasse zu definieren macht nur Sinn ,wenn die basisklasse sie überhaupt nicht kennen braucht.

Wenn du mich fragst hast du definitiv einen Fehler im Design wenn deine Basisklasse Member hat auf die sowohl die Basis als auch eine abgeleitete Klasse schreiben.
Auch eine protected Membervariable ist ungekapselter Zustand. Auch Getter/Setter ändern nix an der Tatsache dass du Implementierungsdetails nach außen trägst.

Demnach wäre das Vorhandensein der Zugriffsspezifizierers "protected" in Programmiersprachen und die Möglichkeit, ihn auf Variablen anzuwenden, grundsätzlich ein Fehler im Design der Sprache, weil es keine Anwendungsfälle gäbe, die nicht ein Fehler im Design des verwendenden Codes wären.
Natürlich ist es sinnvoll, alles, was nicht public API ist, per default erstmal private zu machen und protected nur einzusetzen, wenn tatsächlich abgeleitete Klassen stärkere Zugriffsrechte brauchen als der Rest der Welt.

Ich habe hier z.B. einen Fall vorliegen, wo Änderungen an bestimmten Werten übers Netzwerk synchronisiert werden, das heißt, ich will vermeiden, dass jemand versehentlich einfach auf der Variable direkt herum schreibt. denn public direct access auf die Variable würde bedeuten, dass lokaler Wert und remote-Wert nicht mehr synchron sind.

Wie wärs mit einem Callback wenn ein Wert sich ändert? Dann gibt deine Library nicht vor wie und ob die Daten gespeichert werden müssen...

Wenn mich der momentane Wert x von Foo interessiert, dann finde ich es einfach schöner, wenn ich z.B. einfach if(mFoo.X == mFoo2.X) schreiben kann und nicht selbst mit tracken muss, welche Instanzen von Foo überhaupt existieren, in welcher Foobar-Instanz sie gerade sind, welche Foo-Instanz in welchen Strukturen bei mir wo gespeichert ist und ich will mich dann eben auch nicht darum kümmern müssen, alle Werte für alle Foo-Instanzen in Callbacks upzudaten, nur weil ich zu anderen Zeitpunkten als denen, zu denen die Updates eintreffen, an dem gerade aktuellen Wert interessiert bin. Dafür sorgen, dass lokal die aktuellsten Werte vorliegen, die zu bekommen sind, wenn ich sie gerade brauche, hat die Lib, dafür habe ich sie ja.

D.h. deine Library gibt mir vor dass es Foo gibt die Werte x haben und die Foobar Instanzen gehören?

Ja.

[dot]

Demnach wäre das Vorhandensein der Zugriffsspezifizierers "protected" in Programmiersprachen und die Möglichkeit, ihn auf Variablen anzuwenden, grundsätzlich ein Fehler im Design der Sprache, weil es keine Anwendungsfälle gäbe, die nicht ein Fehler im Design des verwendenden Codes wären.

Wieso? Nur weil eine Sprache etwas erlaubt, bedeutet das noch lange nicht dass es auch gut ist, genauso wie die Tatsache dass es in einem konkreten Kontext nicht gut ist nicht bedeutet, dass es in jedem Fall sinnlos ist?
C++ != OOP != gutes OO Design != Allheilmittel

Natürlich ist es sinnvoll, alles, was nicht public API ist, per default erstmal private zu machen und protected nur einzusetzen, wenn tatsächlich abgeleitete Klassen stärkere Zugriffsrechte brauchen als der Rest der Welt.

Wenn abgeleitete Klassen Zugriff auf Membervariablen der Basis brauchen, dann läuft meiner Meinung nach was schief.
Der Grund ist wohl meistens dass du gerade dabei bist Vererbung nicht zur Modellierung abstrakter Konzepte einzusetzen, sondern als Mittel zur Einsparung von Tipparbeit zu missbrauchen, was definitiv nicht Sinn der Sache ist. Zumindest was OOP betrifft. Zumindest meiner Erfahrung und meinem Verständnis von OOP nach ;)

[kimmi]

Kennst du die SOLID-Regeln? Diese erklären meiner Meinung nach sehr genau, wie sich eine API verhalten sollte. Vielleicht hilft das beim NAchdenken über dein benötigtes Design. Ohne den wirklichen Zusammenhang zu kennen, ist es hier nämlich schwierig, wirklich zu helfen.

Gruß Kimmi

[kaiserludi]

http://en.wikipedia.org/wiki/SOLID_(obj ... ed_design) ?
Bisher nicht unter dem Kürzel, aber an sich ja.

Es ging mir hier eigentlich eher um eine generelle Idee, unabhängig vom konkreten Zusammenhang, ob es eben, wenn Dinge wie Performance eine untergeordnete Rolle spielen, Sinn macht, entsprechend dem Open/closed principle grundsätzlich erst einmal pauschal für das komplette public Interface via virtual die Erweiterung zu ermöglichen (wohlgemerkt die Erweiterung, nicht die Modifikationn und nur diejenigen wengien Methoden nicht virtual zu machen, die aus konkreten Gründen ausdrücklich nicht erweitert werden sollten, z.B. weil sie extrem performance.-kritisch sind. Quasi virtual als default und nicht als Ausnahme (ich glaube, D schlägt diesen Weg bereits auf Sprachebene ein? ).

[kimmi]

Mir fällt da spontan eine Descriptor-Klasse für einen Messwert ein, die das für die Einheit so gelöst hat. Per Default gibt der Getter None zurück ( weil einheitenlos ). Abgeleitetete Klassen können das gegebenenfalls überschreiben. Ob das schön ist: gute Frage, performance-kritisch war es nicht und den Zweck hat es erfüllt.
Wie ich sagte, ist halt Abwägungssache.

Gruß Kimmi