Get() und Set()

Dravere

@Jockelx, Th69,
Auch wenn man es umgehen kann, durch das eigene Programmdesign, das Design der Sprache bleibt gleich und somit schlecht. Wie ich schon sagte, die Idee finde ich extrem toll, die Umsetzung aber nicht. Und weil die Umsetzung schlecht ist, muss man eben sein eigenes Design so anspassen, um dem entgegen zu wirken. Ihr bestätigt grundsätzlich nur meine Aussage, wenn ihr sagt, dass man halt keine öffentlichen Attribute verwenden darf. Wieso gibt es dann überhaupt öffentliche Attribute? Es existiert hier eben eine Inkonsistenz. Es ist nicht ganz sauber durchgezogen.

Grüssli

drakon

Eiffel umschifft das ganze recht elegant.

1. Gibt es keine unterschiedliche Notation für den Aufruf einer Funktion ohne Argumente und einer Datenmember. Datenmember können also public sein und man kann bei Bedarf noch eine Funktion drunter hängen.

2. Die Datenmember sind standardmässig readonly. Das heisst man muss einen setter angeben (mit assign), welcher zum zuweisen benutzt wird.

3. Ob ein Objekt per Value oder per Referenz rumgereicht wird entscheidet nicht der Benutzer der Klasse, sondern der Programmierer der Klasse. (üblicherweise ist es per Referenz, ausser bei so Sachen, wie INTEGER, FLOAT usw.)

class FOO

feature
  n: INTEGER assign set_n -- datenmember + angabe des setters

  bar : INTEGER -- funktion 
  do
     Result := n
  end

  set_n ( n_ : INTEGER )
  do
    n := n_
  end 
end

Der Zugriff erfolg genau gleich:

class BAR
feature
  bar
  local
     f: FOO
  do
    f.create
    f.n
    f.bar -- kein Unterschied

    f.n := 2000 -- der setter wird benutzt
  end
end

Das finde ich wirklich cool.

Sorry für OT, aber da wir eh schon bei C++/C# sind dachte ich, dass ich mal noch eine Alternative reinwerfe, welche imo C# überlegen ist. (natürlich ist mir klar, dass Eiffel für solche Sachen ein Einschränkungen macht, aber das sei aussen vor gelassen. Rein der Mechanismus und Umgehung der Probleme ist richtig gut)

Th69

Und darum z.B. mag ich Java nicht so sehr, weil man dort immer getX() und setX() verwenden muß.

In C++ verwende ich für Properties eine template-basierte Lösung...

P.S. Sorry dravere, aber die Frage finde ich sehr eigenartig - genauso argumentieren ja viele Leute mit C++: warum kann man dies und das machen, obwohl das nur Probleme mit sich bringt? Und C# ist viel regelbasierter designt. Und gerade die einfache Umstellung einer öffentlichen Membervariablen auf ein Property ändert eben nicht die Syntax beim Aufruf (einzig bei Reflection hat dies entsprechende Nachteile). Du siehst, was du als schlechtes Design ansiehst, finde ich (und wohl auch die C#-Designer) dagegen super.
(nicht noch eine Syntax mehr - alleine LINQ und Lambda-Expression sind für viele Anfänger eine große Hürde -)

Nexus

Jockelx schrieb:

Das wird zwar jetzt leider alles etwas OT, aber sei's drum:
Hier (bzw. bei dem was ich sagte) geht es nicht um Design des Programmierers, sondern um das gute Design der Sprache C# und da ist mir Schreibarbeit schon wichtig.
Den C#-Leuten übrigens auch, sonst hätten sie die Kurzschreibweise nicht eingeführt.

Den C++-Leuten offenbar nicht, sonst würden sie Makros für Getter- und Setterfunktionen, deren Implementierung in 95% der Fälle gleich aussieht, verwenden.

Dravere schrieb:

Gleiche Schreibeweise, unterschiedliches Verhalten, sowas nenn ich ein extrem schlechtes Design.

Andere hingegen sprechen von Polymorphie.

Th69 schrieb:

Und darum z.B. mag ich Java nicht so sehr, weil man dort immer getX() und setX() verwenden muß.

Muss man ja gar nicht, dort gibts schliesslich auch public . Allerdings kommt mir die Java-Mentalität grundsätzlich etwas so vor, dass OOP teilweise überbewertet und für Dinge eingesetzt wird, für die man in Sprachen wie C++ andere Konzepte hat (jetzt nicht speziell auf Get/Set bezogen). Von daher wäre ein Java-Programmierer möglicherweise noch stärker abgeneigt gegenüber ungekapselten Klassen.