Defaultwerte überschreiben

Nexus

Dravere schrieb:

Ich habe schon erlebt, dass zum Beispiel ein SetPosition nicht nur die Position gesetzt hat, sondern diese gleich noch übers Netzwerk geschickt hat, obwohl es eigentlich eine weitere Methode gab, welche für das Synchronisieren zuständig war. Stand wunderbar in der Dokumentation, empfand ich allerdings als völlig unlogisch und wäre ich nie darauf gekommen, hätte ich die Dokumentation nicht gelesen. Die grössten Programmierfehler entstehen genau daraus: Der Programmierer nimmt an, dass es so geht, wie er denkt.

Hier sehe ich den Fehler aber mehr beim Bibliotheksentwickler. Bei anti-intuitiven Funktionen darf man sich nicht über Fehlbenutzung wundern. Für irgendwas gibts ja treffende Funktionsnamen und Trennung der Aufgabenbereiche. Bei a-b erwartet auch niemand, dass in Wirklichkeit eine Multiplikation durchgeführt wird und a anschliessend 0 ist.

Natürlich sollte man lieber einmal zu viel als zu wenig in die Dokumentation schauen, besonders wenn man eine Bibliothek noch nicht gut kennt.

Dravere schrieb:

Er sieht diesen Wert aber nicht, weil er sich irgendwo in einem Header befindet, in der tief verschachtelten Hierarchie.

Er sieht den Wert in seiner modernen IDE oder in der Dokumentation, die er lesen sollte. :p

Aber im Ernst: Ich habe schon oft die IntelliSense-Informationen benutzt, um mich über eine Schnittstelle zu informieren. Wenn die Dokumentation gleich über der Funktion steht (z.B. bei Doxygen), ist das viel praktischer als eine externe HTML-Datei abzusuchen.

Dravere schrieb:

Nexus schrieb:

Aber fünf unnötige Methoden sind zuviele (ich spreche immer noch vom Fall, dass ich keinen langfristigen Vorteil durch die Indirektion sehe; nicht dass du mich falsch verstehst).

Das in den Klammern verstehe ich jetzt gar nicht.

Ich entscheide je nach Fall, ob ich NVI für sinnvoll halte oder nicht. In der Klammer ging es mir ums Nicht Sinnvoll. Diese hatte ich am Schluss noch kurz hinzugefügt in der Hoffnung, meine Ansicht zu verdeutlichen. Aber scheinbar habe ich das Gegenteil erreicht und noch mehr Verwirrung gestiftet.

Was ich ursprünglich damit sagen wollte: Du solltest "fünf unnötige Methoden sind zuviele" nicht so verstehen, dass ich durch NVI zusätzlich entstandene Methoden generell für unnötig halte.

Dravere schrieb:

Hier scheint es mir, dass du das Idiom nicht ganz verstanden hast, denn es ist eigentlich gar nie nötig, auf eine virtuelle Methode einer Basisklasse (egal, ob es nur eine Zwischenklasse ist) zuzugreifen.

Danke für die Erklärung. Im Normalfall ist es nicht nötig, das stimmt.

Was ich eigentlich meinte, war Folgendes:

class Fahrzeug
{
    public:
        void TankeAuf()
        {
            // erhalte Möglichkeit für Zusatzbehandlung, Prüfungen etc.
            TankeWirklichAuf():
        }
    private:
        virtual void TankeWirklichAuf() = 0;
};

class Schiff : public Fahrzeug
{
    private:
        virtual void TankeWirklichAuf()
        {
            FuelleHauptTanks();
            FuelleNebenTanks();
        }

        void FuelleHauptTanks();
        void FuelleNebenTanks();
};

class HyperSchiff : public Schiff
{
    private:
        virtual void TankeWirklichAuf()
        {
            Schiff::TankeWirklichAuf(); // <- leider nicht möglich
            FuelleHyperTanks();
        }

        void FuelleHyperTanks();
};

Ich denke aber, wir sehen das Ganze doch nicht so unterschiedlich.

drakon

Nexus schrieb:

Dravere schrieb:

Ich habe schon erlebt, dass zum Beispiel ein SetPosition nicht nur die Position gesetzt hat, sondern diese gleich noch übers Netzwerk geschickt hat, obwohl es eigentlich eine weitere Methode gab, welche für das Synchronisieren zuständig war. Stand wunderbar in der Dokumentation, empfand ich allerdings als völlig unlogisch und wäre ich nie darauf gekommen, hätte ich die Dokumentation nicht gelesen. Die grössten Programmierfehler entstehen genau daraus: Der Programmierer nimmt an, dass es so geht, wie er denkt.

Hier sehe ich den Fehler aber mehr beim Bibliotheksentwickler. Bei anti-intuitiven Funktionen darf man sich nicht über Fehlbenutzung wundern. Für irgendwas gibts ja treffende Funktionsnamen und Trennung der Aufgabenbereiche. Bei a-b erwartet auch niemand, dass in Wirklichkeit eine Multiplikation durchgeführt wird und a anschliessend 0 ist.

Naja. In gewissem sind alle beteiligten Schuld.
Weil es ja explizit in der Dokumentation steht. Ich halte das aber eher für einen Sonderfall, als die Regel. Kommt halt drauf an, auf was für ein Objekt man das aufruft. Von einem string erwarte ich nicht, dass er irgendwelche Sachen ins Netz propagiert, was ich bei einem Socket nicht ausschliessen kann.
Auf der anderen Seite hätten die Entwickler das schon trennen können. Wir (ausser Dravere) können aber die genauen Umstände gar nicht kennen.. Könnte imo schon auch Sinn machen, dass sich die Klasse da unintuitiv verhält.

Klar sollte aber schon die Intuition nicht die Dokumentation ersetzen, sondern sie unterstützen.
Aber z.B habe ich, als ich vor ein paar Monaten mit Java angefangen habe nie wirklich die gesamte Doku zu den Collections gelesen, sondern einfach mehr oder weniger intuitiv benutzt. Wenn ich dann etwas doch nachgelesen habe, dann stand da eigentlich immer sowieso das, was ich angenommen habe. (Elemente einfügen, entfernen, suchen, zugreifen usw. - wüsste nicht, warum ich das lesen hätte sollen)

Dravere

Nexus schrieb:

Hier sehe ich den Fehler aber mehr beim Bibliotheksentwickler. Bei anti-intuitiven Funktionen darf man sich nicht über Fehlbenutzung wundern.

Problem ist, dass das intuitive Empfinden oft sehr subjektiv ist.

Nexus schrieb:

Was ich eigentlich meinte, war Folgendes:

Und wieso nicht so:

class Fahrzeug
{
public:
  void TankeAuf()
  {
    // erhalte Möglichkeit für Zusatzbehandlung, Prüfungen etc.
    TankeWirklichAuf():
  }
private:
  virtual void TankeWirklichAuf() = 0;
};

class Schiff : public Fahrzeug
{
private:
  virtual void TankeWirklichAuf()
  {
    FuelleAlleTanks();
  }

protected:
  void FuelleAlleTanks()
  {
    FuelleHauptTanks();
    FuelleNebenTanks();
  }

  void FuelleHauptTanks();
  void FuelleNebenTanks();
};

class HyperSchiff : public Schiff
{
private:
  virtual void TankeWirklichAuf()
  {
    Schiff::FuelleAlleTanks(); // <- geht doch! ;)

    FuelleHyperTanks();
  }

  void FuelleHyperTanks();
};

Nexus schrieb:

Ich denke aber, wir sehen das Ganze doch nicht so unterschiedlich.

Glaube ich auch nicht

Grüssli

Nexus

Dravere schrieb:

Und wieso nicht so:

Genau.
Aber eben: Streng genommen ist es ja nicht mehr privat. Ich glaube jedoch, wir sind uns einig, was das betrifft.

Danke aber, dass du dir solche Mühe für das Ändern der Einrückung gegeben hast.

Und sorry drakon, dass deine Posts in der Flut untergegangen sind.
(Keine Sorge, ich habe sie schon gelesen und stimme ihnen weitgehend zu :)).

drakon

Nexus schrieb:

Und sorry drakon, dass deine Posts in der Flut untergegangen sind.
(Keine Sorge, ich habe sie schon gelesen und stimme ihnen weitgehend zu :)).

Schon gut. Ich wollt euch ja nicht unterbrechen.

Dravere

Nexus schrieb:

Aber eben: Streng genommen ist es ja nicht mehr privat. Ich glaube jedoch, wir sind uns einig, was das betrifft.

Jein. Man kann es wirklich private machen, wenn man möchte und muss.
Vielleicht nur eine kleine Ergänzung noch, welche mir gestern spät am Abend noch einfiel, wo der Computer aber schon aus war.
Das praktische ist, wenn die virtuelle Funktion aufgerufen wird, dann weiss man, dass es den Aufruf der letzten Überschreibung ist. Die Methode kann schliesslich nicht anders aufgerufen werden (abgesehen davon, wenn der Programmierer es selber in der eigenen Klasse macht). Du hast somit einen sehr klar definierten Zustand, welchen du ausnützen kannst, wenn du musst.

Nexus schrieb:

Danke aber, dass du dir solche Mühe für das Ändern der Einrückung gegeben hast.

Ist das eigentlich dein Standardeinrückungsstil? Sollen wir über sowas auch noch diskutieren?

@drakon,
Oh, du bist ja auch noch hier

Grüssli

Nexus

Dravere schrieb:

Ist das eigentlich dein Standardeinrückungsstil?

Ja. Ein Tab ist bei mir so gross wie vier Leerzeichen, und Zugriffsspezifizierer fangen eingerückt an.

Ich habe mir allerdings auch schon überlegt, ob ich die Einrückungsebene sparen sollte. Z.B. bei switch ist es ähnlich:

switch (var)
{
    case 1:
        Bla();
        break;

    default:
        Bli();
        break;
}

vs.

switch (var)
{
case 1:
    Bla();
    break;

default:
    Bli();
    break;
}

Ich finde die erste Variante leicht übersichtlicher, und der Bildschirm ist eigentlich genügend breit. Klassen haben dann für friend s die gleiche Einrückungsstufe wie für public: .

Du benutzt nur zwei Leerzeichen pro Einrückungsebene?

volkard

Nexus schrieb:

Du benutzt nur zwei Leerzeichen pro Einrückungsebene?

Oh, das ist aber schön. Ich benutze auch gerne zwei.

Dravere

Nexus schrieb:

Du benutzt nur zwei Leerzeichen pro Einrückungsebene?

Im Forum ja, weil es einfacher ist und grundsätzlich nicht mehr benötigt. Ein einziges Leerzeichen ist allerdings zu wenig. Ansonsten verwende ich aber oft Tab und lasse ihn durch 4 Leerzeichen ersetzen. Ich muss allerdings gestehen, dass ich schon mit dem Gedanken gespielt habe, überall auf 2 Leerzeichen runter zu gehen. Es reicht grundsätzlich völlig aus, also wieso noch mehr in die Breite gehen? Vielleicht mache ich mal einen Kompromiss und nehme 3

Grüssli

volkard

In machen Sprachen benutze ich nur eins. Aber drei? Auf die Idee, eine Nicht-Zweierpotenz zu nehmen, wäre ich nie gekommen.