Implementierung 1. --- Input-optimiert

Die Schreibzugriffe werden unmittelbar ausgeführt und die Ausgabe der Fläche wird bei jedem (Lese-)Zugriff neu berechnet.

class Rechteck {
  private:
    int m_laenge;
    int m_breite;

  public:
    Rechteck (int laenge, int breite) : m_laenge(laenge), m_breite(breite) {}

  public:
    const int  getLaenge  ()           {return this->m_laenge        ;}
          void setLaenge  (int laenge) {       this->m_laenge=laenge ;}
    const int  getBreite  ()           {return this->m_breite        ;}
          void setBreite  (int breite) {       this->m_breite=breite ;}

    /** int getFlaeche(void) ist hier für zum Vorteil von 
     *  void setLaenge(int laenge) und void setBreite(int breite)
     *  "langsam" implementiert, da jeder Aufruf von getFlaeche in die 
     *  Berechnung  der Flaeche muendet.
     */
    int  getFlaeche ()           {return (this->m_laenge*this->m_breite) ;}
};

Implementierung 2. --- Output-optimiert

Die Ausgabe der Fläche erfolgt schnell, weil sie bereits berechnet vorliegt und wenn sich die dafür zugrundeliegenden Parameter m_laenge oder m_breite ändern, wird die Fläche sofort neu berechent und gespeichert.

class Rechteck {
  private:
    int m_laenge;
    int m_breite;
    int m_flaeche; /* NEU */
  public:
    Rechteck (int laenge, int breite) : m_laenge(laenge), m_breite(breite)     {this->consolidate() ;}

  public:
    /** NEU  Wenn m_laenge oder m_breite über die entsprechenden set-Methoden
     *  geändert, wird jedesmal die Fläche neu berechnet. Die Methode hierfür
     *  nenne ich consolidate(), weil sie den inneren Zustand konsolidiert.
     */
          void consolidate ()           {this->m_flaeche=(this->m_laenge*this->m_breite) ;}
    const int  getLaenge   ()           {return this->m_laenge        ;}
          void setLaenge   (int laenge) {       this->m_laenge=laenge; consolidate() ;}
    const int  getBreite   ()           {return this->m_breite        ;}
          void setBreite   (int breite) {       this->m_breite=breite; consolidate() ;}
    const int  getFlaeche  ()           {return this->m_flaeche       ;}
};

Implementierung 3. --- Input/Output-optimiert

Hier wird die Fläche nur berechnet, wenn sich m_laenge oder m_breite geändert haben. Dafür sind die Schreibzugriffe wegen des Aufrufes von setInvalid() nur etwas langsamer als in Implementation 1, der Lesezugriff auf m_flaeche im Idealfall nur etwas langsamer als in Implementation 2 wegen der Prüfung auf Gültigkeit (m_validity) und die Fläche wird nur neu berechnet, wenn sich die zugrundeliegenden Parameter (m_laenge und m_breite) geändert haben UND die Fläche auch tatsächlich gebraucht wird.

class Rechteck {
  private:
            int  m_laenge;
            int  m_breite;
    mutable int  m_flaeche;
    mutable bool m_validity; /* NEU */

  public:
    Rechteck (int laenge, int breite) : m_laenge(laenge), m_breite(breite) {}

  public:
          void consolidate ()           {this->m_flaeche=(this->m_laenge*this->m_breite); this->setValid() ;}
    const int  getLaenge   ()           {return this->m_laenge        ;}
          void setLaenge   (int laenge) {       this->m_laenge=laenge; this->setInvalid() ;}
    const int  getBreite   ()           {return this->m_breite        ;}
          void setBreite   (int breite) {       this->m_breite=breite; this->setInvalid() ;}
          bool isInvalid   ()           {return (!this->m_validity)     ;}
    const int  getFlaeche  ()           {if (this->isInvalid()) consolidate(); return this->m_flaeche ;}
  private:
          void setValid    ()           {this->m_validity=true          ;}
          void setInvalid  ()           {this->m_validity=false         ;}
};

Ich hoffe da sind jetzt keine mehr Bugs drin

außerdem denkt bei IO-optimierten zugriffen jeder an high-performace dateioperationen.

das stimmt nicht.

Danke für diese Vorschläge

@Volkert Nein, es geht hier nicht um das zwischenspeichern von Ergebnissen, sondern um die Optimierung von get&set-Methoden. Wenn es sich bei dem Rechteck um eines handelt, bei dem sich häufig Seitenlängen ändert ist Implementierung 1. angesagt. Wenn die Seitenlängen sich selten ändern aber häufig die Fläche benötigt wird, dann ist Implementierung 2. die bessere Lösung. Wenn aber die Zugriffe häufig zwischen Lesen und Schreiben wechseln, ist die 3. Implementation die günstigste Lösung. Daß hierfür Ergebnisse zwischengespeichert werden müssen, ist ebend unumgänglich. Diesen Punkt heranzuziehen um das ganze "Caching" zu nennen, gefällt mir nicht. Ich selber nenne es für mich auf denglisch Data-Flow-Optimation - also Datenfluß-Optimierung. Findet jemand diesen Begriff anstößig?

Nein, es geht hier nicht um das zwischenspeichern von Ergebnissen, sondern um die Optimierung von get&set-Methoden. Wenn es sich bei dem Rechteck um eines handelt, bei dem sich häufig Seitenlängen ändert ist Implementierung 1. angesagt. Wenn die Seitenlängen sich selten ändern aber häufig die Fläche benötigt wird, dann ist Implementierung 2. die bessere Lösung. Wenn aber die Zugriffe häufig zwischen Lesen und Schreiben wechseln, ist die 3. Implementation die günstigste Lösung. Daß hierfür Ergebnisse zwischengespeichert werden müssen, ist ebend unumgänglich.

es geht ums caching. und du erklärst fein, daß caching von berechnungsergebnissen oder sonstwelchen aufwendigen operationen. und du zeigst auch, daß sowas mit kosten verbunden ist, weshalb man vorher fein überlegen sollte, ob sich das auch lohnt. schreibt man sehr viel und liest sehr selten, sollte man das schreiben so performant wie möglich machen und das lesen kann ruhig ohne caching sein. liest man sehr viel und schreibt sehr selten, sollte man das berechnungsergebnis vorhalten und bei jedem schreiben neuberechnen. liegt man irgendwo dazwischen, kann es sich anbieten, das ergebnis erst auf anfrage zu berechnen und bis zum nächsten schreiben zu cachen.

Diesen Punkt heranzuziehen um das ganze "Caching" zu nennen, gefällt mir nicht.

komisch.

Ich selber nenne es für mich auf denglisch Data-Flow-Optimation - also Datenfluß-Optimierung. Findet jemand diesen Begriff anstößig?

das klingt irgendwie nach detenflußoptimierung statt nach caching.

IO hört sich schicker an Na gut ... dann nenn ich diesen Thread get&set-Optimierung.

Danke für diese Vorschläge

@Volkert Nein, es geht hier nicht um das zwischenspeichern von Ergebnissen, sondern um die Optimierung von get&set-Methoden. Wenn es sich bei dem Rechteck um eines handelt, bei dem sich häufig Seitenlängen ändert ist Implementierung 1. angesagt. Wenn die Seitenlängen sich selten ändern aber häufig die Fläche benötigt wird, dann ist Implementierung 2. die bessere Lösung. Wenn aber die Zugriffe häufig zwischen Lesen und Schreiben wechseln, ist die 3. Implementation die günstigste Lösung. Daß hierfür Ergebnisse zwischengespeichert werden müssen, ist ebend unumgänglich. Diesen Punkt heranzuziehen um das ganze "Caching" zu nennen, gefällt mir nicht. Ich selber nenne es für mich auf denglisch Data-Flow-Optimation - also Datenfluß-Optimierung. Findet jemand diesen Begriff anstößig?

Lol. Solange du aber *nicht* mehr ausser nur Caching machst IST es eben einfach Caching und keine "Datenflussoptimierung" oder sonstwas.
Mann, Mann, Mann ...

rule number one of optimization:
don't do it.