Was gilt als gutes OOP ?

Nexus

Der Artikel enthält etwas viel Bla Bla, aber in gewissen Punkten hat er Recht.

Why getter and setter methods are evil schrieb:

Getter and setter methods (also known as accessors) are dangerous for the same reason that public fields are dangerous: They provide external access to implementation details.

Zu einem gewissen Teil stimmt das, vor allem wenn man Member 1:1 und präventiv auf entsprechende Getter/Setter abbildet. Auf gewisse Eigenschaften muss vor aussen gar nicht zugegriffen werden, oder der Zugriff muss nur lesend oder schreibend erfolgen, oder indirekt durch eine Aktion. Allerdings gibt es sehr wohl Situationen, in denen man Eigenschaften der Klasse direkt ändern muss, ganz ohne Setter/Getter kommt man nicht vernünftig aus.

GutesOOP? schrieb:

Kann man also generell sagen, dass es nicht so wichtig ist ? Bzw. dass es schlicht weg auf die Situation an kommt und sowohl private als auch public gleich oft benutzt werden ?

Nein, public sollte sparsam eingesetzt werden. Halte Schnittstellen schmal. Gerade in C++ hast du im Gegensatz zu Java die Möglichkeit, die Funktionalität einer Klasse durch freie Funktionen zu erweitern. Nutze sie.

volkard

Nexus schrieb:

cooky451 schrieb:

<<OOP Hasser>>

Nicht-Kenner triffts besser. Welchen Vorteil Getter und Setter haben, ist wohl eines der ersten Dinge, die einem bei OOP erklärt werden.

Ja. Und erst recht spät lernt man, sie korrekt zu meiden.

cooky451

Nexus schrieb:

cooky451 schrieb:

<<OOP Hasser>>

Nicht-Kenner triffts besser.

War damit gemeint, wollte mich nur nicht gleich vor allen outen.

Ich verstehe den Sinn hinter Gettern/Settern schon, aber halt nur wenn sie mehr machen als "m_x = x" und "return m_x".

Nexus

volkard schrieb:

Ja. Und erst recht spät lernt man, sie korrekt zu meiden.

Das ist ein generelles Problem, das der OOP-Hype mit sich bringen kann. Andere Beispiele sind der übermässige Einsatz von Vererbung, das Immer-polymorph-Machen von Basisklassen oder das Vermeiden globaler Funktionen ("nicht objektorientiert, weil nicht in Klasse").

Du bringst es gut auf den Punkt: Schwieriger als die korrekte Verwendung ist die korrekte Nicht-Verwendung

cooky451 schrieb:

Ich verstehe den Sinn hinter Gettern/Settern schon, aber halt nur wenn sie mehr machen als "m_x = x" und "return m_x".

Auch solche Getter/Setter können Sinn machen, besonders weil man jederzeit die Möglichkeit hat, mehr Funktionalität zu implementieren, ohne User-Code zu beeinträchtigen.

camper

Was haben Getter und Setter mit OOP zu tun?

Was machen die die keine Getter und Setter wollen, bei folgendem Beispiel?

Bei einem 3D-Modellierungs-Programm hat man Objekte (Boxen, Linien...), denen kann man eigentlich auch immer Namen geben. Dazu gibt es in irgendeinem Editor, in dem auch noch alles mögliche andere eingestellt werden kann, auch ein Feld für den Namen. Wenn jetzt ein User dort einen Namen eingibt, ruft ihr dann nicht object.setName(...) auf? Was dann?

volkard

butterbeidiefische schrieb:

Dazu gibt es in irgendeinem Editor, in dem auch noch alles mögliche andere eingestellt werden kann, auch ein Feld für den Namen. Wenn jetzt ein User dort einen Namen eingibt, ruft ihr dann nicht object.setName(...) auf? Was dann?

Doch, da schon.
Aber im Spiel wird's vermutlich kein setName geben, sondern im Konstruktor wird der Name geladen und nie mehr verändert.

Kann es sein, dass die Getter/Setter-Gegner davon ausgehen, dass man total dämlich programmiert? Also anstatt vector.push_back irgendwie getSize, getArrayPointer, ... setArrayPointer, setSize(++size), setValue...

cooky451

butterbeidiefische schrieb:

object.setName(...) auf? Was dann?

Noe, ich mach das mit object.name = "blubb"

cooky451 schrieb:

butterbeidiefische schrieb:

object.setName(...) auf? Was dann?

Noe, ich mach das mit object.name = "blubb"

Was dumm wäre, wenn du auch noch etwas anderes machen willst, z.B. Callbacks für nameChanged.

cooky451

Sorry aber dein Post kam irgendwie so sinnlos, da musste das einfach sein

brotbernd

Implementierungsdetails einer Klasse privat zu machen gehört nun zu den absoluten Basics von OOP. Nur weil du eine Klasse schreibst und vor Daten ein private schreibst,programmierst du noch lange nicht objektorientiert.
Gute OOP fördert die Erweiterbarkeit, Flexibilität und Wartbarkeit von Software durch Abstraktion, Kapselung und Reduzieren von Abhängigkeiten (das Verhindern einer Abhängigkeit zu irgendeiner bestimmten Variable gehört da als einfachstes Mittel dazu). Als Einstieg in gute OOP kann ich die sog. SOLID Prinzipien als Lesestoff empfehlen (google solid oop).
Über den Sinn und Unsinn von Getter/Setter wird hier ja fast wöchentlich erneut diskutiert, ich weiß gar nicht warum. Daten von nicht trivialen Typen sind privat und wenn die niemanden was angehen schreibt ich keine Getter/Setter. Man schreibt grundsätzlich nichts was man nicht braucht. Und wenn man so einfache Daten wie einen Namen manipulieren oder auf den Bildschirm schreiben will, dann gibt es dafür halt eine öffentliche Schnittstelle. Man könnte zwar auch die Klasse selber auf den Bildschirm schreiben lassen, aber die sich daraus ergebene Abhängigkeit zu Ein-/Ausgabe Techniken ist viel schlimmer als eine zusätzliche Schnittstelle. Mit const hat man in C++ ja auch eine schöne Kontrolle über diese Zugriffe.

Nexus schrieb:

cooky451 schrieb:

<<OOP Hasser>>

Nicht-Kenner triffts besser. Welchen Vorteil Getter und Setter haben, ist wohl eines der ersten Dinge, die einem bei OOP erklärt werden.

Leider wird selbst (oder gerade?) an Unis auch nicht viel mehr gelehrt. Es gibt zu viele Entwickler die Getter und Setter mit Kapselung gleich setzen und null Ahnung haben wieviel mehr hinter diesem Begriff steckt.

Dazu wird noch alles in eine Klassenhierarchie gestopft und schon hat man ein tolles OO-System

Ich setze Getter/Setter (bzw. Properties in C#) nur für relativ unkritische Datenfelder ein. Zu viel Logik in den Xettern ist verwirrend und verursacht jede Menge klasseninterne Abhängigkeiten. Dann packe ich das lieber in eine Methode mit sprechendem Namen.