Schlechter Stil wenn man alle public: hat?

Apollon schrieb:

Setter verletzen das Information-Hiding-Prinzip. Das macht dann natuerlich das Pattern ueberfluessig.

Kannst du mir mal ein vernünftiges Beispiel zeigen, bei dem man das Visitor pattern einsetzt anstelle eines setters?

Und ganz nebenbei, meine Antwort bezog sich, wie deutlich zu erkennen auf das Zitat und nicht auf Getter/Setter.

So wie du zitierst macht der (Neben)Satz für mich keinen Sinn. Wenn ich mir den Satz davor anschau, dann schon.

Selbst wenn Getter und Setter nichts großartiges machen, machen sie Sinn. Weil was ist, wenn ich später doch mehr machen muß?

Und dann gehts doch um setter und getter.
Oder was soll

Weil was ist, wenn ich später doch mehr machen muß?

bedeuten?

Artchi

Also wie mir ein Visitorpattern anstatt eines Setters helfen soll, frage ich mich ehrlich.

Ausgangssituation:

class A
{
public:
  int b;
};

int main()
{
    A a;
    a.b = 1;
}

So, irgendwann will ich das Verhalten der Klasse A so ändern:

class A
{
  private:
      int b;
      bool changed;

  public:
      void serB(int b)
      {
           if(b != this->b)
               changed = true;
           this->b = b;
      }
      int getB()
      {
           return b;
      }
};

int main()
{
    A a;
    a.setB(1);
}

1. Wenn ich vorher alles public hatte, nur weil bei setten nicht viel passiert, habe ich ein Problem, wenn ich es später doch private setze, weil ich mehr machen will. Z.B. Status ändern. Ich muß im gesamten Projekt die Compile-Errors beheben. Wenn es sich um eine verbreitete Klasse oder Library handelt, habe nicht nur ich ein Problem, sondern auch alle anderen Nutzer. Schlecht wenn sich auf einmal die API stark ändert.

2. Wie kann mir bei einer Schnittstellenänderung bitte ein Visitorpattern helfen?

Also, ich mache lieber von Anfang an alles private, selbst wenn ein setter nicht viel macht. Aber ich kann so viel flexibler das Verhalten einer Klasse ändern, ohne das der Klassenbenutzer etwas davon mitbekommen. DAS ist Kapselung. Und nicht wenn der Benutzer nachher bei einem Update der Klasse/Lib vor einem Compile-Error-Wald steht.

Apollon

Eigentlich sollten sich Schnittstellen nicht aendern und Member gegen Zugriffe von aussen geschuetzt werden (private und keine Getter/Setter). Solltest Du dann die Klasse um weitere Funktionalitaet erweitern wollen (spaeter mehr machen), hilft dir da das Visitor-Pattern. Und im gutem Design gehoeren konkrete Klassen sowieso nicht zur Schnittstelle.

DEvent

Und im gutem Design gehoeren konkrete Klassen sowieso nicht zur Schnittstelle.

Stimmt, also auch keine Public-Attribute. Thema erledigt, nächstes Problem bitte.

Apollon schrieb:

Eigentlich sollten sich Schnittstellen nicht aendern und Member gegen Zugriffe von aussen geschuetzt werden (private und keine Getter/Setter). Solltest Du dann die Klasse um weitere Funktionalitaet erweitern wollen (spaeter mehr machen), hilft dir da das Visitor-Pattern.

Wenn ich später neue Funktionen brauch, dann kann ich die auch so dazu machen, da brauch ich nicht das Visitor pattern. Es ging aber auch nie darum weitere funktionen einzubauen, sondern beim setzen eines Wertes noch etwas zusätzliches zu machen.

Und im gutem Design gehoeren konkrete Klassen sowieso nicht zur Schnittstelle.

Was verstehst du unter Schnittstelle?

Ist das hier schlechtes Design oder wie würdest du das machen?
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/Statement.html
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html
Wie soll ich den Daten abfragen oder setzen ohne getter und setter?

PS: Ich mach den Witz gleich, dann braucht ihr ich nicvht mehr machen: Java ist sowieso schlechtes Design. Muhahaha...

lolz

Worauf willst du hinaus? Diese Methoden setzen doch einen Parameter auf einen gewissen wert, oder holen einen Parameter als einen bestimmten wert. Hiermit will man doch gar keine Attribute der Klasse auslesen oder setzen.

Walli

Knuddlbaer schrieb:

Naja, der VC hat als Erweiterung Properties im Angebot. Das endet auch nur daran, das man set und get schreiben muss. Der Aufwand beim Programmieren ist so der gleiche, die Verwendung schaut dann anderst aus.

Alt:
class T
{
  int m_member;
public:
   int member();
   void member(int i);
}

T t;

t.member(12);
int a = t.member();
Im VC mit der neuen Erweiterung:
class T
{
  int m_member;

public:
   property member()
   {
      int get();
      void set(int i);
   }
}

T t;

t.member = 12;
int a = t.member;
Das Problem ist viel mehr der Aufwand die get und set Methoden zu schreiben.

Was spräche denn gegen eine Erweiterung die das explizite hinschreiben der getter/setter Methoden unnötig macht wenn sie nicht mehr machen als den Wert rauszugeben bzw. zu setzen? Das wäre dann wieder so was ähnliches wie public, aber soweit ich weiß kann man keine Pointer auf Properties holen. Richtig?

Jester

Eigentlich nichts, außer vielleicht dass es ein sehr sehr spezielles Problem löst. Dann doch lieber richtige properties so wie in der VC-Erweiterung. Damit kriegste das auch alles. Wenn dann die einfachen getter/setter noch generierbar sind finde ich das recht komfortabel.

lolz schrieb:

Worauf willst du hinaus? Diese Methoden setzen doch einen Parameter auf einen gewissen wert, oder holen einen Parameter als einen bestimmten wert. Hiermit will man doch gar keine Attribute der Klasse auslesen oder setzen.

Wieso sollen das dann keine Attribute der Klasse sein? Ich denke schon das z.B. die connection in member ist und mit getConnection geholt wird. Mich hätte ja interessiert, wie da das visitor pattern helfen soll.

Walli

Jester schrieb:

Eigentlich nichts, außer vielleicht dass es ein sehr sehr spezielles Problem löst. Dann doch lieber richtige properties so wie in der VC-Erweiterung. Damit kriegste das auch alles. Wenn dann die einfachen getter/setter noch generierbar sind finde ich das recht komfortabel.

Ja, das meinte ich. Properties wie in der VC-Erweiterung, aber wenn sie nicht explizit angegeben werden, dann werden normale getter/setter erzeugt. Ich habe aber keine Ahnung, ob das nicht sowieso schon geht mit dem VC.

lolz

BuddyHollysBrille schrieb:

lolz schrieb:

Worauf willst du hinaus? Diese Methoden setzen doch einen Parameter auf einen gewissen wert, oder holen einen Parameter als einen bestimmten wert. Hiermit will man doch gar keine Attribute der Klasse auslesen oder setzen.

Wieso sollen das dann keine Attribute der Klasse sein? Ich denke schon das z.B. die connection in member ist und mit getConnection geholt wird. Mich hätte ja interessiert, wie da das visitor pattern helfen soll.

Möglicherweise hat sie die Connection als Attribut gespeichert, aber das tut nichts zur Sache und kann dir als Benutzer der Klasse auch egal sein. Denn du willst mit der Klasse bzw. einem Objekt der Klasse arbeiten und nicht mit dessen Attributen.

lolz schrieb:

Möglicherweise hat sie die Connection als Attribut gespeichert, aber das tut nichts zur Sache und kann dir als Benutzer der Klasse auch egal sein. Denn du willst mit der Klasse bzw. einem Objekt der Klasse arbeiten und nicht mit dessen Attributen.

Ja. Eigentlich wollte ich ja auch wissen wie am mit dem Strategiepattern das besser machen kann, aber naja.

Apollon

Ok. Nochmal was ich meine. Ich vertrete die Meinung, dass Member private oder zumindest protected sein sollten und es keine Setter/Getter geben soll. Den Zustand eines Objektes repraesentiert das Objekt selbst. Es muss nicht extra ausgelesen werden und darf nicht beliebig gesetzt werden. Objekte kollaborieren mit Objekten, nicht mit deren Membern. Wenn man nun weitere Funktionalitaet hinzufuegen moechte und Vererbung nicht ausreicht, da man explizit Zugriff auf Member braucht, kann dass Visitor-Pattern einem abhelfen.

Was "flexible" Setter/Getter angeht kann ich nur sagen: ein set/get hat eine feste Semantik. Es setzt bzw. gibt zurueck. Sobald es darueber hinausgeht, verdieht die Funktion einen anderen Namen, denn sie setzt/liefert nicht nur, sondern geht darueber hinaus.

Zum Java Design: ein Stack ist kein Vector und verhaelt sich auch nicht so. Es verletzt daher das LSP. Deswegen lasse ich dieses Authoritaetsargument auch nicht zu (Zumal man als erwachsener, selbstdenkender Mensch jede Authoritaet kritisch hinterfragen sollte).