spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Weil Getter und Setter logischerweise immer gebraucht werden. Wenn du mir erzählen möchtest, dass eine gute OOP keine Eigenschaften eines Objektes veröffentlichen soll. Ich wüsste ehrlich gesagt nicht, warum das so schlechtes Design ist. Das man keine Attribute einer Klasse direkt veröffentlicht ist klar, aber Properties bzw. Getter- und Setter sind doch vollkommen legitim. Und ich finde es eher eine ziemlich ungünstige Einschränkung, wenn man keine Eigenschaften veröffentlicht. Ich kenne auch ehrlich gesagt genau 0 Projekte, sei es OpenSource oder ClosedSource, die diesen Ansatz verfolgen. Was soll denn der Vorteil davon sein, außer das die Schnittstellen vielleicht genauer, aber komplizierter werden?

Zitat von »TrommlBomml«

Weil Getter und Setter logischerweise immer gebraucht werden.

I beg to differ, meiner Erfahrung nach braucht man Getter und Setter extrem selten. So selten, dass mir gerade nichtmal ein Beispiel einfällt, wo man welche brauchen könnte...

Zitat von »TrommlBomml«

Wenn du mir erzählen möchtest, dass eine gute OOP keine Eigenschaften eines Objektes veröffentlichen soll.

Was genau meinst du mit "Eigenschaften"?

Zitat von »TrommlBomml«

Ich wüsste ehrlich gesagt nicht, warum das so schlechtes Design ist.

Weil es Implementierungsdetails der Klasse aus der Schnittstelle leaked. Oft selbst dort noch wo nicht einfach nur direkt ein Datenmember exposed wird, was allerdings bei einem beachtlichen Teil aller Properties, über die ich bisher so gestolpert bin, leider der Fall ist...

Zitat von »TrommlBomml«

Was soll denn der Vorteil davon sein, außer das die Schnittstellen vielleicht genauer, aber komplizierter werden?

Die Schnittstellen werden meiner Erfahrung nach wesentlich klarer und einfacher. Inbesondere hilft es, die Kopplung von verwendendem Code an einen konkreten Typ zu vermeiden und steigert damit die Wiederverwendbarkeit...

Wenn man Properties verbieten will, weil sie unsauberen (im Sinne der OOP) Code ermöglichen, sollte es auch mechanismen geben, die Getter und/oder Setter unterbinden, die lediglich einen Wert einem Member zuweisen oder den Wert eines Members zurückliefern.
Der Grund, der gegen Getter und Setter spricht, dürfte die Verwendung sein. Deine (dot) Meinung dazu dürfte, wenn ich mich nicht irre, sein, dass man grundsätzlich nur einen Getter oder nur einen Setter braucht, da es andernfalls häufig schlechtes Design dazu führt, beides zu haben.
Übertragen auf die Properties heißt das aber auch nur, dass auf diese von außen auch nur entweder lesend oder schreibend zugegriffen werden sollte. In C# gibt es bspw. die Möglichkeit, dass der Setter oder der Getter privat sind, wodurch diese nicht von außen verwendet werden können, man aber dennoch die Wertprüfungen (im Falle eines privaten Setters), die ggf. durchgeführt werden, bei jeder Zuweisung ausgeführt werden.

Ich finde dots Hintergründe berechtigt, Properties sollten aber dennoch aufgenommen werden.

Auch angucken könnte man sich in dem Zusammenhang die Herangehensweise von Python. Und wenn man schon einen Blick auf Python wirft, kann man sich auch die Magic Member ansehen, über welche das Standardverhalten (bspw. Operatorüberladung) beeinflusst wird.
Ich finde diese Lösungen in Python durchaus elegant (es entstehen nicht unmengen von Schlüsselwörter bzw. die vorhandenen werden nicht je nach Kontext anders interpretiert), allerdings auch im Kontext von Python. Ich will also nicht sagen, dass du dich daran orientieren sollst, allerdings kann es nicht schaden, andere herangehensweisen gesehen zu haben.

Das klingt für mich alles ziemlich wage und theoretisch. Mit Eigenschaften meine ich Felder einer Klasse. Programme bestehen doch nunmal aus Daten und Logik. Ich denke bestes Beispiel ist doch wohl Darstellung von Daten. Wenn du getrennte Schichten für Darstellung und Logik hast, dann muss die Darstellung die Daten aus der Logik-Schicht bekommen. Wie soll das denn bitte ohne Getter gehen?! (Ich vernachlässige jetzt mal aus Einfachsheitsgründen Darstellungsobjekte, bspw. ViewModels).

@dot:
Was ist denn mit sowas wie SetPosition oder SetColor für irgendwelche grafischen Objekte? Oder SetCaption für ein GUI-Element?
Wie würdest du das anders machen? Klar könnte man SetPosition auch MoveTo nennen (oder so ähnlich), aber im Kern bliebe es dasselbe.

War ich wirklich so langsam im Schreiben meines Beitrags? (Hatte dots Beitrag nicht gesehen...)

Dagegen habe ich auch nichts gesagt. In diesem Fall muss die View Daten aus den antsprechenden Objekten erhalten, sie muss aber keine Daten zuweisen. Und seitens der Logik könnte es ausreichend sein, die Daten dem Konstruktor zu übergeben.

Ein anderes Beispiel wäre eine Klasse, die bspw. eine Internetverbindung aufbauen soll (z. B. für ein Spiel über Internet). Eine Eigenschaft dieser Klasse könnten die Informationen über die aktuell offene Verbindung sein (entfernte Adresse, entfernter Port, ...). Man könnte auf die Idee kommen, über das Zuweisen von Werten an diese Eigenschaft die Verbindung zu ändern, allerdings sollte dafür (meiner Meinung nach) eine separate Methode vorhanden sein, da das Aufbauen der Verbindung ggf. das Beenden der aktuellen Verbindung erfordert, der Aufbau der neuen Verbindung fehlschlagen kann etc. Wenn erst die bestehende erfolgreich abgebaut wurde und der Aufbau der neuen Verbindung fehlschlagen würde, würde unerwarteterweise ein leerer Eintrag an dieser Stelle stehen, da keine Verbindung da ist. Man könnte diesen Fall vermeiden, indem man daraufhin einen Wiederaufbau zum vorherigen Server durchführt, allerdings kann auch dieser fehlschalgen und es ist dennoch grundsätzlich nicht mehr der gleiche Zustand.


@David:
Diese könnten auch im Konstruktor zugewiesen werden.
Wenn sich eine Überschrift ändern kann, dann hat man entweder eine feste Anzahl an Überschriften und einen eigenartigen Mechamismus zum Ändern des Inhalts oder der Inhalt richtet sich nach bestimmten Objekten im Hintergrund.
ein Beispiel für letzteres könnte eine Serverliste und eine Vorschau des selektierten Servers sein. Dort gäbe es eine Überschrift, die den Namen des selektierten Servers anzeigt (oder die Felder, die andere Daten anzeigen). In dem Fall wäre es ohnehin angenehmer, wenn man nicht die Daten selbst setzen müsste, sondern definieren könnte, woher die Daten bezogen werden.
Wenn man letzteres machen kann, dann dürfte es an anderen Stellen ziemlich uninteressant sein, was diesem Element als Datenquelle zugewiesen wurde.
Wenn der Text fest zugewiesen ist, dann wird er auch nur einmal gesetzt und sollte dann auch gänzlich unwichtig sein.

Wen man will, kann man an dieser Stelle um einen Setter herum kommen (Zuweisen beim Konstruktoraufruf), wenn das Design allerdings nicht über code vorgenommen wird bzw. beim generierten Code die Eigenschaften nicht über den Konstruktor zugewiesen werden können (bspw. bei WPF der Fall), ist ein Setter erforderlich.
In beiden Fällen sollte ein Getter aber nicht notwendig sein (und der Setter nur einmalig aufgerufen werden).


@LetsGo:
Soweit ich das einschätze, geht es hier nicht um Getter+Setter vs. direkter Zugriff, sondern um Getter+Seter vs. entweder Getter oder Setter.

Zitat von »David Scherfgen«

@dot:
Was ist denn mit sowas wie SetPosition oder SetColor für irgendwelche grafischen Objekte? Oder SetCaption für ein GUI-Element?
Wie würdest du das anders machen? Klar könnte man SetPosition auch MoveTo nennen (oder so ähnlich), aber im Kern bliebe es dasselbe.

Danke David! Meine Rede. Wenn man das alles vermeidet, dann wird der Code meiner Meinung nach vielleicht irgendwo strikter und klarer, aber doch auch komplizierter.

Zitat von »Spiele Programmierer«

Ich bin auch grundsätzlich gegen die Philosophie, Programmierer durch die Sprache disziplinieren zu wollen.

Dito.

Und Davids Beispiel ist mir auch als erstes Eingefallen. SetPosition, SetColor etc. brauche ich persönlich für Grafik Objekte sehr häufig.
Warum sollte man das nur über Konstruktoren machen? Die Position kann sich ja ständig ändern.

Die Attribute für setter und getter will ich also auf jeden Fall einbauen, bzw. habe es schon.
Auch möchte ich die Attribute noch erweitern. Ein weiteres Attribut gibt es z.B. für Klassen:


Wird zu:

Das habe ich z.B. oft gebraucht, wenn ich Strukturen direkt aus einer Datei lesen wollte.
Da aber der Compiler bei Optimierung Byte-Alignments nach belieben einbauen kann, sollte das dadurch verhindert werden.

Die Syntax mit dem '#' gefällt mir noch nicht so gut, bisher ist das aus Gründen des Parsers so gelöst.
(Eigentlich wollte ich das wie in HLSL mit bspw. dem "[unroll]" Attribut machen.)

Zur (mitlerweile) etwas älteren Frage:

Zitat von »dot«

Gibt es eigentlich schon ein Konzept von Klassen oder überhaupt eines Typsystems? Wie sieht es mit Vererbung aus?

Mit Vererbung habe ich auch schon angefangen, allerdings wird diese Sprache nicht (wie bswp. C# oder Java) eine rein OOP Sprache werden.
Nicht alles muss also ein Objekt sein (afaik ist in C# sogar jedes Integer-Literal ein Objekt).
Ich persönlich erachte u.A. Interfaces - die erzwungener Maßen keine Funktions-Implementierungen haben können - als eher unwichtig in einer Sprache.
Wer ein reines Interface habe will, der soll eine reine abstrakte Klasse schreiben - das geht mit meiner Sprache auch, so wie in C++ mit "virtual ... = 0",
bei mir heißt es dann halt "abstract ...".

EDIT:

Zitat von »dot«

Du hast offenbar eingebautes Reference Counting? Wie genau werden zyklische Abhängigkeiten vermieden bzw. behandelt? Gibt es andere Formen von Besitzverhältnissen? Wenn nein würde mich interessieren, wieso du dich gerade für Reference Counting entschieden hast.

Es gibt standard C++ pointer und smart pointer, aber nur smart pointer können allokiert werden, weil es nur managed memory geben soll.
So könnte man z.B. eine Baumstruktur anlegen, ohne dass Zyklen beim Reference-Counting entstehen:


Ich habe genau deshalb Reference-Counting ewählt, weil das schon in C++11 und boost implementiert ist.
Außerdem halte ich Garbage-Collection für ineffizienter (zumindest was die Leistung betrifft).
In Objective-C z.B. wird GC zwar generell unterstützt, für iPhone/ iPad ist es aber nicht verfügbar.

Zitat von »Spiele Programmierer«

Ich kann Dots Argumentation ehrlich gesagt auch nicht ganz nachvollziehen.
Ich bin auch grundsätzlich gegen die Philosophie, Programmierer durch die Sprache disziplinieren zu wollen.

Eine Meiner Meinung nach sehr interessante Sprache ist "D".
Properties werden dort als "Set*" bzw. "Get*" im Namen deklariert, wobei man auf entsprechende Funktionen dann zugreifen kann wie auf Properties in C#. So etwas finde ich in so fern sinnvoll, als das ein unnötiges Syntaxkonstrukt eingespart wird.

Das ist bzw. war Konvention. Der D Compiler kann schon seit Ewigkeiten Methoden/Funktionen wie Properties behandeln, will heißen, dass man leere () weglassen kann. Gab auch einige Zeit lang die Debatte, dass solche Methoden extra mit @property markiert werden müssten und der -property Flag wurde eingeführt. Mittlerweile ist aber mehrheitlich abgestimmt worden, dass für jede Methode die leeren () weggelassen werden dürfen (z.B. für UFCS), wie ursprünglich vorgesehen. Daher wird @property deprecated und der -property Flag abgeschafft werden. Aber das ist wohl schon etwas Offtopic, wollte es nur klar stellen.