Schlechter Stil wenn man alle public: hat?

DEvent

Stell dir einfach vor eine Klasse ist Mensch. Die Objekte davon sind Maria und Joseph.

Wenn jetzt alle Attribite public wären, dann würde das bedeuten das du z.B. deren Testosteronspielgel, Blutzuckerwert und die Anzahl der Weißen Blutkörperchen direkt setzten könntest. Ausserdem die Haarfarbe, Augenfarbe und ihr Geschlecht. Die Namen und deren Familienzugehörigkeit natürlich auch.

Ist doch wie mit Messern. Ab einen gewissen Alter dürfen Kinder damit rumhantieren.

Dein Beispielt aufzunehmen: Die Klasse ist Messer. Wenn jetzt die Attribute public wären, wäre es einfacher meinMesser.kaputt = false zu setzten, anstatt es reparieren zu lassen. Das meinMesser.klingeImArsch == true und meinMesser.schärfe == 0.0 immernich gilt stört mich dabei nicht.

Wenn du ein Attribut direkt setzt kannst du nicht wissen ob Attribute die davon abhängen, nun falsche Werte haben.

Hallo

lolz schrieb:

Getter und Setter sind auch nicht viel besser..

Eine Klasse soll abstrahieren und nicht ein Datencontainer spielen.

Natürlich schreibt man nicht für jeden Member einne Setter und Getter, sondern nur für die, auf die man zugreifen soll.

chrische

thordk

es ist grundsätzlich kein schlechter stil, alles public zu machen.

das problem dabei ist, dass du vielzuviel verwaltungsaufwand hinterherschieben musst, um konsistente funktionsweise deiner methoden zu gewährleisten.

beispielsweise ein counter als membervariable, der darüber buch führt, wieviele elemente von irgendwas intern erzeugt wurden. wenn nun dieser counter von aussen manipuliert wird, hast du keine chance, das mitzubekommen, wodurch womöglich andere methoden nicht mehr korrekt funktionieren.

deshalb ist anständige kapselung schon sinnvoll.

Michael E.

thordk: Du könntest Nachrichtensprecher werden. Die sagen auch erst "Guten Abend" und erklären dann ne halbe Stunde, warum es kein guter Abend ist.

DrGreenthumb

OOpler schrieb:

Nun habe ich mir aber überlegt einfach immer alles public zu haben.
Jetzt kann zwar jeder auf alles zugreifen, aber ich denke ab einem
gewissen Zeitpunkt muss man doch davon ausgehen können, dass nicht jeder
alles einfach verändert. Ist doch wie mit Messern. Ab einen gewissen Alter dürfen Kinder damit rumhantieren.

Sehe ich genauso. Und langsam tendiere ich auch dazu, einfach alles immer public zu machen. Gekapselt wird ja trotzdem. Membervariablen werden von außen einfach generell nicht angerührt.

So ist es bequemer. Private Hilfsfunktionen müssen nicht mehr in die Klassendefinition und man kann zum Testen auch mal von außen auf die Variablen zugreifen.

pock

DrGreenthumb schrieb:

Sehe ich genauso. Und langsam tendiere ich auch dazu, einfach alles immer public zu machen. Gekapselt wird ja trotzdem. Membervariablen werden von außen einfach generell nicht angerührt.

Kannst du so tun, wenn du deine kleine Telefonnummern-Verwaltung für den Hausgebrauch selbst programmierst. Solltest du mal einen Job in der Richtung haben wollen, solltest du die Einstellung vielleicht nochmal überdenken, bevor du dich irgendwo bewirbst. Niemand stellt jemanden ein, von dem man vorher schon weiß, dass er mehr Bugs produzieren wird als brauchbaren Code.

Datenkapselung ist ein Grundpfeiler der Objektorientierten Programmierung. Wenn ihr dafür zu faul seid, programmiert lieber in BASIC oder Brainf*ck.

DrGreenthumb

Datenkapselung ist ein Grundpfeiler der Objektorientierten Programmierung.

Habe mich nicht gegen Datenkapselung ausgesprochen.

DEvent

DrGreenthumb schrieb:

Datenkapselung ist ein Grundpfeiler der Objektorientierten Programmierung.

Habe mich nicht gegen Datenkapselung ausgesprochen.

Doch du hast:

Und langsam tendiere ich auch dazu, einfach alles immer public zu machen

DrGreenthumb

DEvent schrieb:

DrGreenthumb schrieb:

Habe mich nicht gegen Datenkapselung ausgesprochen.

Doch du hast:

Und langsam tendiere ich auch dazu, einfach alles immer public zu machen

dann lies mal bitte auch den nächsten Satz

Aber ich formuliere mal um:
Langsam tendiere ich dazu, einfach //private statt private: zu schreiben.

Jetzt klar worauf ich hinauswollte? Ich finde die Kontrolle durch die Sprache unsinnig. So hatte ich auch die ursprüngliche Frage verstanden.

Zumal (wie ich auch schon schrieb, was aber offenbar keiner gelesen hat) Variablen ohnehin _immer_ private sein sollten.

pock

DrGreenthumb schrieb:

Ich finde die Kontrolle durch die Sprache unsinnig.

Ich dagegen finde die Kontrolle durch die Sprache alles andere als unsinnig. Die Zugriffskontrolle kann gar nicht rigide genug sein und sie gehört vor allem beim Schnittstellen-Design zu den elementaren Bausteinen. Du wärst erstaunt, was so mancher "Programmierer" mit deinem Code alles anstellt, wenn er es KANN, weil das Interface schlecht oder gar nicht durchdacht wurde.

Letzten Endes werden daraus immer Bugs, die voll und mit Recht auf deine Kappe gehen.

Und defaultmäßig alles public machen und irgendwann mal den Schalter umlegen... warum nicht von Anfang an über sauberes Design nachdenken? Solche Späße sind dann gar nicht notwendig.

private und const sollten die Lieblingsworte jedes C++-Programmierers sein. Wer den Sinn dieser Konstrukte in Frage stellt, stellt den Sinn der ganzen Sprache in Frage.

lolz

Ich kann deine Argumentation ja durchaus verstehen DrGreenthumb aber es schützt dich und andere einfach vor Programmierfehlern, genauso wie es const tut.
Warum solltest du von außen jemals auf eine private Methode zugreifen wollen, wenn du das wirklich brauchst, dann sollte diese Funktionalität in der öffentlichen Schnittstelle enthalten sein.
Den Zugriff auf die Daten für Tests kann ich durchaus nachvollziehen, das mach ich manchmal auch so, allerdings ändere ich das dann später wieder.

Natürlich ist es sinnvoll betsimmte Methoden nicht öffentlich zu machen. Einfaches Beispiel: Du hast eine Methode, die um sinnvolle Ergebnisse zu liefrn, bestimmte Bedingungen braucht. Sind diese Bedingungen nicht erfüllt, macht diese Methode keinen Sinn. Machst du diese Methode nun private, kannstd u mit einer public Methode sicherstellen, dass das deine private Methode nur dann aufgerufen wird, wenn die Randbedingungen erfüllt sind. Ein anderer Programmierer kommt gar nicht in die Verlegenheit sie aufzurufen, weil er es gar nicht kann.
Ähnlich verhält es sich mit Gettern und Settern. Nehmen wir an ein Attribut darf nich null sein. Wie willst du das ohne Setter sicherstellen, wenn dieses Attribut öffentlich ist?

rüdiger

Das Problem sind eben fehlende Getter/Setter bei C++. So etwas nachzurüsten ist zwar möglich, aber auch nicht ganz so schön. So steht man eben oft da, wenn man mal wieder ein Häufchen Daten zu einer Klasse zusammenfasst und im Grunde nichts anderes schreibt, als ein getA/setA für jede Variable.

Luckie schrieb:

Natürlich ist es sinnvoll betsimmte Methoden nicht öffentlich zu machen. Einfaches Beispiel: Du hast eine Methode, die um sinnvolle Ergebnisse zu liefrn, bestimmte Bedingungen braucht. Sind diese Bedingungen nicht erfüllt, macht diese Methode keinen Sinn. Machst du diese Methode nun private, kannstd u mit einer public Methode sicherstellen, dass das deine private Methode nur dann aufgerufen wird, wenn die Randbedingungen erfüllt sind. Ein anderer Programmierer kommt gar nicht in die Verlegenheit sie aufzurufen, weil er es gar nicht kann.
Ähnlich verhält es sich mit Gettern und Settern. Nehmen wir an ein Attribut darf nich null sein. Wie willst du das ohne Setter sicherstellen, wenn dieses Attribut öffentlich ist?

Wobei die Vorbedingungen auch zu einer interessanten Frage führen. Ist ein Integer-Typ der in [A; B] liegen soll, wirklich der gleiche Integer-Typ, der in [C; D] (C!=A, B!=D) liegen soll?

Natürlich kann man sich das nicht so leicht machen, wenn man Vorbedingungen hat, die von mehreren Membern einer Klasse abhängig sind.

Knuddlbaer

Grundlegend stellt sich doch die Frage was entwickelt wird.

Software zur weiteren Entwicklung ?
Schnitstellen ?
Standardsoftware ?

Oder vllt. Individualsoftware , bei der es auf Stunden ankommt ?`

Generell sollte man so viel wegkapseln wie nur irgend machbar aber
manchmal ist etwas schlechter Stil einfach Wirtschaftlicher. Es bringt einen garnichts wenn man extrem saubere Programme hat aber keine Aufträge.

Den Endkunden interessiert es nicht ob die Software sehr sauber und Zukunftssicher geschrieben ist, den interessiert es nur ob er 3 oder 6 Manntage für das Ergebnis zahlen muss.

Solange das Projekt jedoch nicht solchen Regeln unterstellt ist, sollte man private und const zum liebsten Arbeitsmittel machen, so verlernt man es nicht und kann durch die Erfahrung besser entscheiden, wo schlampigkeit bei Zeitdruck weniger weh tut

Walli

Ich finde es grundsätzlich merkwürdig, wenn jemand Klassen mit zig get/set schreibt und die wirklich auch nur das tun. Das hat überhaupt nichts mit OOP zu tun und man kann die Member gleich alle public machen. Wenn ein set aber noch eine andere Funktion erfüllt, nämlich z.B. weitere Abhängigkeiten aktualisieren usw. dann ist es natürlich etwas anderes. Am liebsten wäre mir wenn C++ so etwas wie Properties bekäme und man Variablen einfach mit obj.var holen bzw. setzen könnte. Noch schöner ist es allerdings, wenn man vom internen Aufbau des Objektes überhaupt nichts von außen mitbekommt. Aber dass dies nicht immer ganz einfach ist brauche ich wohl nicht erwähnen.

Knuddlbaer

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.
Daher neigt man dazu, einfach ein public: davor zu schreiben.

ABER

Wenn jetzt eine Änderung im Quellcode notwendig wird und man plötzlich vor Verwendung des Members abfragen machen muss, wird es schwer, da sich das Interface ändert. (Mit dem property im VC geht es noch, da bleibt wenigstens der Clientcode gleich, ggf muß man aber alles neu Übersetzen, muss ich jetzt passen).

UND

mittels get und set kann man steuern ob nur geschrieben , nur gelesen oder gelesen und geschrieben werden kann.

Das was man an Zeit durch ein einfaches "public:" spart, kann einen hinterher mehrfach diese kosten.

Es macht manchmal sinn einfach public zu nehmen (siehe oben) aber es ist mit entsprechenden Nachteilen behaftet und wird bei bedarf entsprechend bestraft. (Die Strafen fallen mit zunehmender Erfahrung aber geringer aus :D)

mathik

Why getter and setter methods are evil:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html

Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

mathik schrieb:

Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

Und wer hat die Getter und Setter? Das Objekt. Also macht doch mit den Gettern und Settern das Objekt die Arbeit.

Und wenn Faulheit ein Grund ist schlechten Code zu schreiben, dann hat man offnsichtlich seinen Beruf verfehlt.

Vielleicht solltest du nicht alles in Klassen packen, sondern manchmal ganz einfach Strukturen verwenden, wenn das ding sowieso keine Funktionen hat.
Falls es in einer Klasse wirklich so viele attribute gibt, auf die du zugreifen musst, dann könnte das auch an nem schlechten design liergen. Vielleicht in mehrere Klassen aufteilen, oder ganz umstrukturieren. Die Klassen sollen doch was tun (render, move,...) und nicht nur als Datencontainer dienen.

Artchi

Was stört euch jetzt hauptsächlich? Die Schreibarbeit um getter/setter zu schreiben? Dann besorgt euch vernünftige C++ Tools! Ein Beispiel? Hier:

Membervariable _mymember angelegt:
http://www.kharchi.de/files/cpp/getter1.png

Kontextmenü zu der Memebervariable geöffnet um Getter/Setter autom. generieren zu lassen:
http://www.kharchi.de/files/cpp/getter2.png

Fertig :
http://www.kharchi.de/files/cpp/getter3.png

So, da mache ich mir heute keinen Kopf drüber, ob es mich Schreibarbeit kostet. Weil es nunmal ruckzuck mit zwei Mouseclicks geht. Vernünftige C++ Tools vorausgesetzt.

Members sollte man immer kapseln. Wobei ich pers. folgender Regel nachgehe:
1. Alle Memebervariablen private.
2. Getter und Setter erstelle ich erst nach Bedarf.
3. Selbst wenn Getter und Setter nichts großartiges machen, machen sie Sinn. Weil was ist, wenn ich später doch mehr machen muß? Z.B. eine Statusänderung vermerken muß? Wenn ich die Members public habe, wird das schwierig. Selbst wenn ich es nachträglich private mache, werden woanders Compile-Errors auftauchen, die man beheben darf. Was auch Arbeitszeit kostet.