spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Naja ich muss den Artikeln wiedersprechen. Getter dienen dazu ein Objekt nach ausen preiszugeben Ohne dabei die speicherung zu berücksichtigen. Z.b. kann ich bei einem Getter on the fly ein Objekt erzeugen wenn das basis Objekt noch nicht erzeugt ist. Oder ich kann aus einer Liste/Array mir daten holen. Würde ich nun Direkt auf die Variablen zugreifen und ZUSÄTZLICH Getter anbieten wäre das sehr unsauber. Daher ist es deutlich sauberer und mehr im sinne von OOP Getter und Setter einheitlich überall zu verwenden. Das Argument wieso der Code dadurch unhandlicher und schwere wartbar sein soll leuchtet mir da ehrlich gesagt nicht so ein.

Zitat

Meine Erfahrung ist, dass Getter und Setter meistens Symptome von
schlechtem OO Design sind. Und offenbar bin ich da nicht allein:

Wie validiere ich die öffentlichen Eigenschaften ohne Getter/Setter?
Wie sorge ich dafür, dass spätere Änderungen meiner Klasse an diesen Eigenschaften die Anwendung nicht beeinflussen?

Und genau DAS sind Kernfunktionen eines guten OOP Designs

Es geht nicht darum ob man die Variablen öffentlich macht oder stattdessen lieber getter und setter benutzt. Es ist hier fast jedem Klar, dass getter und setter besseres Design sind als öffentliche Variablen.
Es geht darum, sein Design so auszulegen, dass man möglichst ohne getter und setter klar kommt.
Natürlich kann man nicht pauschal sagen, dass getter und setter schlecht sind. Ein gutes Beispiel sind Container. Sie haben Grundsätzlich setter und getter für ihre Elemente und getter die Größe. Das heißt nicht, dass Container schlechtes design sind. Eher im Gegenteil.
Dot geht es darum, dass Container z.B. keine setter/getter für interne Daten, wie dem Zeiger auf das dahinterliegende Array haben. Stattdessen gibt einen Iterator für das erste Element, der für eine sehr nützliche Indirektionsebene sort. So brauch es den Nutzer des Containers nicht interessieren ob es eine verkettete Liste oder eine Array ist(aus Sicht des Codes, nicht der Performance).

Zitat von »fkrauthan«

Naja ich muss den Artikeln wiedersprechen. Getter dienen dazu ein Objekt nach ausen preiszugeben Ohne dabei die speicherung zu berücksichtigen.

"Ein Objekt nach außen preisgeben" widerspricht den Grundprinzipien der OOP.

Zitat von »fkrauthan«

Z.b. kann ich bei einem Getter on the fly ein Objekt erzeugen wenn das basis Objekt noch nicht erzeugt ist. Oder ich kann aus einer Liste/Array mir daten holen. Würde ich nun Direkt auf die Variablen zugreifen und ZUSÄTZLICH Getter anbieten wäre das sehr unsauber. Daher ist es deutlich sauberer und mehr im sinne von OOP Getter und Setter einheitlich überall zu verwenden. Das Argument wieso der Code dadurch unhandlicher und schwere wartbar sein soll leuchtet mir da ehrlich gesagt nicht so ein.

Das eigentliche Problem fängt dort an, wo du meinst, irgendwie auf die Daten in einem Objekt zugreifen zu müssen. Denn das bedeutet im Kontext mit OOP eigentlich meist, dass deine Daten schlicht und einfach am falschen Ort untergebracht sind. Getter und Setter sind kaum besser als public Member.

Zitat von »Kevni«

Wie validiere ich die öffentlichen Eigenschaften ohne Getter/Setter?

Das ist nicht das Problem. Das Problem ist, dass du öffentliche Eigenschaften hast.

Zitat von »Kevni«

Wie sorge ich dafür, dass spätere Änderungen meiner Klasse an diesen Eigenschaften die Anwendung nicht beeinflussen?

Gar nicht

Zitat von »NachoMan«

Es geht nicht darum ob man die Variablen öffentlich macht oder stattdessen lieber getter und setter benutzt. Es ist hier fast jedem Klar, dass getter und setter besseres Design sind als öffentliche Variablen.
Es geht darum, sein Design so auszulegen, dass man möglichst ohne getter und setter klar kommt.

exakt

Zitat von »NachoMan«

Natürlich kann man nicht pauschal sagen, dass getter und setter schlecht sind. Ein gutes Beispiel sind Container. Sie haben Grundsätzlich setter und getter für ihre Elemente und getter die Größe. Das heißt nicht, dass Container schlechtes design sind. Eher im Gegenteil.

Ich würde Container nicht unbedingt als Beispiel für OOP sehen. OOP setzt man normalerweise eher auf höherer Ebene ein.

Das man Setter/Getter nur für Eigenschaften definiert wofür sie benötigt werden steht außer Frage.
Auf sinnlose Methode die man sicher nie braucht kann man immer verzichten. Eigenschaften die nie nach außen gehen sollen bekommen weder Getter noch Setter und sind privat. Eigenschaften die keine validierung benötigen, also einfach nur durchgereicht werden, sollten aus meiner Sicht auch Getter/Setter haben um falls man später mal doch validierungen hinzufügt, die Programme die diese Klasse verwenden nicht anpassen zu müssen.

Zitat

Das ist nicht das Problem. Das Problem ist, dass du öffentliche Eigenschaften hast.
...

Gar nicht

Dann verstehe ich nicht wieso du gegen Setter/Getter bist. Gegen öffentliche Eigenschaften sind Getter/Setter auf private Eigenschften doch die Lösung? >.<

Nochmal: Das Problem ist nicht wie genau man sowas wie "öffentliche Eigenschaften" realisiert. Getter und Setter sind sicherlich besser als öffentliche Member. Aber sie ändern nichts am eigentlichen Problem, nämlich der Tatsache dass interner Zustand nach außen propagiert wird...

Jein. Wenn man Getter und Setter *richtig* implementiert erstellen sie eine Kopie und geben eben NICHT die interne Variable nach außen. Womit sie wieder voll die OOP Prinzipien erfüllen.

Nochmal: Darum geht es nicht. Ob kopiert wird oder nicht, ob öffentliche Variablen oder Getter und Setter ist völlig egal. Es geht um die Struktur des sich ergebenden Designs. Wenn du Daten, egal in welcher Form, aus einem Objekt herausholen musst, um dann damit zu arbeiten, dann bedeutet das, dass diese Daten im falschen Objekt sind, an der falschen Stelle in deiner Struktur.

Gib mir einfach mal ein Beispiel, wo du meinst, unbedingt Getter und Setter zu benötigen und ich zeig dir, wie es ohne funktionieren würde...

Design patterns Z.b. das MVC Pattern