Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
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.
Was soll denn der Vorteil davon sein, außer das die Schnittstellen vielleicht genauer, aber komplizierter werden?
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Administrator
Es ist ja keine Schande etwas falsch zu machen, als Programmierer tu ich das täglich, [...].
Zitat
Wen man will, kann man an dieser Stelle um einen Setter herum kommen
Zitat
Man könnte auf die Idee kommen, über das Zuweisen von Werten an diese Eigenschaft die Verbindung zu ändern,
Zitat
In beiden Fällen sollte ein Getter aber nicht notwendig sein
@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.
Ich bin auch grundsätzlich gegen die Philosophie, Programmierer durch die Sprache disziplinieren zu wollen.
Quellcode |
|
1 2 |
// Pack-Attribut (#p) #p class Test { /* ... */ } |
C-/C++-Quelltext |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
#if defined(_MSC_VER) # pragma pack(push, packing) # pragma pack(1) # define __XX__PACK_STRUCT__ #elif defined(__GNUC__) # define __XX__PACK_STRUCT__ __attribute__((packed)) #else # define __XX__PACK_STRUCT__ #endif class Test { /* ... */ } __XX__PACK_STRUCT__; #ifdef _MSC_VER # pragma pack(pop, packing) #endif #undef __XX__PACK_STRUCT__ |
Zitat von »dot«
Gibt es eigentlich schon ein Konzept von Klassen oder überhaupt eines Typsystems? Wie sieht es mit Vererbung aus?
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.
Quellcode |
|
1 2 3 4 5 6 |
class BinaryTree { int data BinaryTree* parent // (non-owner) BinaryTree@ childA // (owner) BinaryTree@ childB // (owner) } |
Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »LukasBanana« (16.01.2014, 14:16)
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.
Werbeanzeige