Klassen ohne getter/setter?

[Kenner des SideWinder]

SideWinder schrieb:

Sieht mir sehr danach aus, dass C++ Properties als Sprachfeature fehlen?!

MfG SideWinder

Du willst doch nur einen Flamewar provozieren.

[DEvent]

Wir scheinen verschiedene Auffassungen von Aufgaben von Objekten zu haben. Es ist meiner Meinung nach ungünstig, jedes Objekt als Eigenschaften-Container zu betrachten und sich zu fragen: "Was hat das Objekt?"; und das, was das Objekt hat (seine Eigenschaften), kann man dann auslesen und/oder setzen.
Es ist doch imho erstrebenswerter, sich zu fragen, welche Aufgabe ein Objekt hat, was es also kann. Man steuert damit dann auf eine Schnittstelle zu, die definiert, zu was das Objekt in der Lage ist, und nicht, welche Daten es enthält. Denn das kann uns als Benutzer des Objekts doch völlig egal sein.

Ich stimm dir doch zu, allerdings hast du mit deinem "Datei" eher die Daten beschrieben, nicht eine Datei. Deine Datei hat nur Methoden um auf die Daten zuzugreifen, aber nichts um auf die Datei zuzugreifen.

Egal ist eh OT.

Es geht doch gar nicht um Performance, sondern um stilistische Vor-/Nachteile, z.B. wie gut der Code wartbar, erweiterbar oder die Implementation austauschbar ist.

Dann verstehe ich die Diskussion erst recht nicht.

Geht es darum statt getter/setter direkt auf die Attribute zuzugreifen?

Denn getter/setter benoetigst du auf jeden Fall, und wenn du sie statt setXXX/getXXX eben read(), write() und seek() nennst. Wenn du das Kind Max statt Alex nennst, bleibst es doch ein Kind.

Edit:

Hast du den Unterschied zu dem Aufruf von DataModel::Instance()->getThis()->getThat()->getDataSet()->insertData( ... ); verstanden?

Ah darum gehts? Dann heist der Artikel: Abstraktion von Internen Strukturen und deren Vorteil vs direkten Zugriff auf alles?

[Artchi]

Zitat:
Hast du den Unterschied zu dem Aufruf von DataModel::Instance()->getThis()->getThat()->getDataSet()->insertData( ... ); verstanden?

Ah darum gehts? Dann heist der Artikel: Abstraktion von Internen Strukturen und deren Vorteil vs direkten Zugriff auf alles?

Dann geht es doch aber nicht generell um getter/setter? Sondern darum, ob ich mir eine Abhängigkeit in meinem Code aufbaue, oder durch eine betsimmte Methode den get-get-Strang verstecke?

Also, irgendwie stehe ich immer noch im Regen. Zuerst kristalisierte sich mehr heraus, das es an der Namensgebung liegt (setSize vs. resize) obwohl es in der Implementierung gleich ist. Doch jetzt gehts anscheinend "nur" um die zu vermeidende Abhängigkeit? (was Sinn macht)

Entweder ist jemand so nett und schreibt einen schönen Artikel darüber, wo wir aufgeklärt werden, oder ich sollte in Zukunft so weiter machen ohne Zweifel ("Oh nein, getter/setter sind doch angeblich schlecht, was mache ich jetzt?").

[Badestrand]

DEvent schrieb:

Badestrand schrieb:

Es geht doch gar nicht um Performance, sondern um stilistische Vor-/Nachteile, z.B. wie gut der Code wartbar, erweiterbar oder die Implementation austauschbar ist.

Dann verstehe ich die Diskussion erst recht nicht.

Also ich denke nicht, dass es generell bei Getter/Setter vs anders um Performance geht, das dürfte sich wahrscheinlich ziemlich die Waage halten.

DEvent schrieb:

Denn getter/setter benoetigst du auf jeden Fall, und wenn du sie statt setXXX/getXXX eben read(), write() und seek() nennst. Wenn du das Kind Max statt Alex nennst, bleibst es doch ein Kind.

Hehe, das ist wahr Naja, es ist imo ein wenig schwierig zu definieren, was nun ein Getter/Setter ist. Wenn Getter einfach alle Methoden sind, mit denen man sich Informationen aus dem Objekt holt und Setter alle befehlsartigen Methoden sind, dann sind sie definitiv unverzichtbar, Objekte könnten ja sonst gar nicht kommunizieren.
Ich verstehe unter Gettern und Settern aber eher eine spezielle Art von Methoden, ich will's mal versuchen darzustellen:

class Sonstwas
{
public:
    void SetFoo( Foo* p ) {ptr=p;}
    Foo* GetFoo()         {return ptr;}

private:
    Foo* ptr;
}

Etwa so halt, wie Artchi das mit dem pModel bei MVC skizziert hatte; man hat ein Objekt und setzt ihm ein bestimmtes Objekt rein oder holt es heraus. Oder auch Klassen, bei denen quasi alle Attribute abfragbar und setzbar sind:

class Sonstwas
{
public:
    // Hier Getter und Setter für jedes Attribut.
private:
    int attr1;
    str attr2;
    foo attr3;
}

DEvent schrieb:

Ah darum gehts? Dann heißt der Artikel: Abstraktion von Internen Strukturen und deren Vorteil vs direkten Zugriff auf alles?

Vielleicht, ja Nein, aber genau solche Aufruf-Kaskaden bekommt man oft, wenn man mit obigen Gettern/Settern arbeitet.

Tut mir Leid, wenn ich anscheinend ein wenig am Thema vorbeigeredet hab

[Badestrand]

PS: Was wären für euch denn Methoden, die weder Getter noch Setter sind?

[ich_du_er]

Badestrand schrieb:

PS: Was wären für euch denn Methoden, die weder Getter noch Setter sind?

Aktionen. foo.do_something();

[Artchi]

Etwa so halt, wie Artchi das mit dem pModel bei MVC skizziert hatte; man hat ein Objekt und setzt ihm ein bestimmtes Objekt rein oder holt es heraus.

Und wie soll das Widget das Model kennen? Es geht dabei nicht darum, das Model zu verwalten, sondern nur zu kennen. Oder wie stellt ihr Verbindungen zu Objekten her?

Am Ende geht es hier anscheinend nur darum, wie die Funktion heißt? Soll heißen, die Anti-Setter-Getter-Fraktion stört sich nur am Funktionsnamen? Denn vorallem bei OOD kann ich nie sagen, was hinter setX wirklich passiert. Wird tatsächlich nur ein Attribut neu gesetzt? Oder passiert da vielleicht nicht doch mehr?

Beispiel MVC:

// Pseudocode:

class Widget
{
      Model *model;
public:
      void setModel(Model *m)   // evil?
      {
           model = m;
           model->addObserver(this);
      }

      void observe(Model *m)   // besser weil kein setter-Name???
      {
           model = m;  // set Model!
           model->addObserver(this);
      }

      ~Widget()
      {
          model->removeObserver(this);  // wie sonst, wenn es kein set model gibt?
      }
};

Klar, observe() als Funktionsname ist nicht schlecht. Aber die Implementierung ist in beiden Fällen gleich. Man kann also gerne darüber diskutieren, ob man immer den richtigen Namen für eine FUnktion wählt, aber das model = m; schlecht sein soll, kann ich nicht verstehen!!! Ich muß doch irgendwo mir meine Beziehungen merken dürfen, um mit ihnen zu aggieren (siehe z.B. Destruktor!).

[Shade Of Mine]

Das Problem mit getter/setter ist wie mit goto. Zuviel verwenden ist furchtbar aber gleich garnicht verwenden ist mindestens genauso furchtbar.

Getter/Setter werden liebend gerne für alle internen Variablen genommen aber nur ein Bruchteil des internen States hat nach aussen zu gelangen (aber dieser Bruchteil muss nach aussen).

[Bashar]

Artchi schrieb:

Etwa so halt, wie Artchi das mit dem pModel bei MVC skizziert hatte; man hat ein Objekt und setzt ihm ein bestimmtes Objekt rein oder holt es heraus.

Und wie soll das Widget das Model kennen? Es geht dabei nicht darum, das Model zu verwalten, sondern nur zu kennen. Oder wie stellt ihr Verbindungen zu Objekten her?

Im Konstruktor.

[Artchi]

Und wenn ich später ein anderes Model haben will? Denn eine View ist ja nicht für immer dazu verdammt ein und das selbe Model zu kennen. Ich will auch auf ein anderes Model zur Laufzeit umschalten können. Und jetzt?

Wie gesagt: bitte keine Ideal-Beispiele. Im Ctor kann ich natürlich alles erschlagen und den Anwender des Objektes massiv in der Handhabung zur Laufzeit des Objektes einschränken. Sprich: hast du einmal das Objekt erzeugt, darfs du nichts mehr damit machen/ändern. Ist das die Devise?

[phlox81]

Das heisst aber nicht das du ein SetModel(Model* m) benötigst:

bool View::ChangeModel(int ModelID)
{
  Model* m = Controller::Instance().GetModel(ModelID);
  if(!m)
    return false;
  model = m;
  Update();
  return true;
}

[Artchi]

Das wird ja hier immer verrückter! Jetzt soll ich IDs hin und her schieben, wo doch ein Objekt selbst schon eine ID hat (die Adresse). Also alles doppelt gemoppelt verwalten? Macht das alles natürlich viel wartbarer.

Neee, also lasst mal Leute. Das ist ja alles noch schlimmer als wenn ich es weiterhin so mache, wie bisher. Überzeugt hat mich das ganze nicht. Eher abgeschreckt. Bis auf das man vielleicht seine Methoden anders bennen könnte/sollte (anstatt setSize lieber resize usw.), habe ich aus der Diskussion nicht viel für mich neues gewinnen können.

Vielleicht haben andere etwas gewinnen können.

[Bashar]

Artchi schrieb:

Und wenn ich später ein anderes Model haben will?

Dann brauchst du wohl zwangsläufig eine set-Methode. Die Frage ist: Brauchst du sie auch, wenn du später kein anderes Model haben willst?

[Artchi]

Nein, dann natürlich nicht. Ich habe genug Klassen, wo z.B. etwas im Ctor übergeben wird, und es sich später nicht ändert. Aber das ist einfach meine pers. Designentscheidung für eine spezielle Klasse und nicht weil ich setter evil finde. Und mir geht es in diesem Thread eigentlich darum, das ich öffters im Forum lese das getter/setter evil sind, weil sie schlechtes Design sind. Also will ich eine Alternative wissen, und nicht einen speziellen Fall, weil der gerade ins Konzept passt. Und ich will keine Alternative wo ich Mehraufwand habe (siehe ID).

Denn ganz ehrlich? Ich habe mir Sorgen gemacht, das ich irgendwas verpasst habe. Deshalb auch die ernsthafte (!) Anfrage nach einem solchen Artikel.

[Badestrand]

Artchi schrieb:

Am Ende geht es hier anscheinend nur darum, wie die Funktion heißt? Soll heißen, die Anti-Setter-Getter-Fraktion stört sich nur am Funktionsnamen?

Nein, ist bei mir jedenfalls nicht so.

Beispiel MVC:

class Widget : public IBlaObserver
{
public:
    Widget()
    {
        Model::addObserver( this );
    }

    ~Widget()
    {
        Model::removeOberserver( this );
    }
};

Es kann sein, dass ich den Fall nur noch nicht hatte, aber wozu braucht man bei MVC ein wechselndes Modell? Oder wann würde es Sinn machen, dass verschiedene View-Elemente auf verschiedenen Modellen arbeiten? Und wenn ein Modell-Wechsel stattfindet, wieso sollte der Wechsel im View stattfinden und nicht im Modell oder einem Controller, der sich nach außen hin wie ein Modell gibt?

Ups, hatte den Beitrag vor ~2 Stunden angefangen, mir kam dann was dazwischen, wollte die Diskussion nicht wieder anheizen.

[Artchi]

EDIT: Beitrag auf den es sich bezog ist out of date.

[Apollon]

Knuddlbaer schrieb:

Apollon schrieb:

Knuddlbaer schrieb:

und wie kommt man an die nötigen Daten rann ?

Hoe? Man hat doch freien Zugriff drauf... Ach! Du meinst von aussen?! Nochmal: man reicht nicht Daten rum, sondern Objekte.

Davon das Du Deine Aussage wiederholst, wird sie nicht besser. Was fange ich mit einem Objekt an, das ich übergeben bekommen habe ?

Mit doofen Fragen wirst Du sie aber auch nicht schlechter machen.

Knuddlbaer schrieb:

Was bringt mir ein Objekt, das Berechnungen vornimmt wenn man die Daten nicht verwenden kann ?

var ErgebnissAnDemIchInteressiertBin = ObjektDasIchBekommenHabe.BerechneErgebnis(Parameter)

[Badestrand]

Wir könnten ja einige Präzendenzfälle zusammentragen (wie hier den MVC-Fall), wo dann im Artikel Alternativen aufgezeigt werden. Einen ganz allgemeinen Artikel zu schreiben, ist doch sicherlich ziemlich schwierig.

[mathik]

Artchi schrieb:

Also mich würde mal ein Artikel freuen, wie man denn Klassen-Designs ohne Getter und Setter hinbekommen soll. Lese hier immer wieder im Forum, das manche Leute es ein schlechtes Design finden. Aber mich würde mal interessieren, wie das ganze denn real umgesetzt werden sollte?

Wie würde man z.B. sowas "besser" lösen können:

class Widget
{
    public:
       void setModel(Model);
       Model getModel();
};

http://www.pragprog.com/articles/tell-dont-ask

[isdochquatsch]

Wenn ich einfach nur irgendwo ne Schriftgröße abfragen und ändern will, wie soll man den sowas ohne getter und setter machen?