Original geschrieben von Norbert Eder
Gut, ohne IDE ist es nicht zu erkennen - gebe ich Dir recht.
Hier ist es allerdings so, dass die Core-Klassen des Frameworks da keinen Code ausser Überprüfungen ausführen. Bei eigenen Klassen weißt Du was passiert und ansonsten gibt es noch eine Dokumentation. Gibt es keine Dokumentation war der andere Programmierer unsauber und so wird vermutlich auch die Componente bzw. der Code dahinter aussehen.
Wenn ich mich in einen Code reinarbeite dann lese ich diesen. Die beste Dokumentation ist der Code.
Doku brauch ich bei Dingen die nicht so einfach herauszulesen sind.
Eine Variablenzuweisung ist aber nichts wofür ich extra in der Doku nachschlagen will ob es ein Property ist oder eine Variable.
Original geschrieben von Norbert Eder
Aus diesen Blickwinkeln stellt dies absolut kein Problem dar.
Liest du dich in andere Projekte bei jeder Zeile Code in der Doku nach?
Also ich habe nicht die Zeit jede Zeile durchzugehen und mit meiner IDE zu inspizieren
ob da noch was dahinter steckt.
Eine Programmiersprache (von der IDE abgesehen) muss mir die Möglichkeit liefern
den Code zu erfassen, das ist Aufgabe der Programmiersprache, und wenn diese das
Aufgrund eines Designfehlers nicht kann, dann ist das schlecht. Sprich dein genannter
Nachteil von Java get und set Methoden zu schreiben ist eigentlich ein Vorteil gegenüber
.net.
Das wirst du, so uneinsichtig wie du mannchmal bist, wieder nicht einsehen und mit irgendwelchen
Argumenten wie eben das sogar kostenlose IDEs das darstellen können oder dieses und jenes
tool gibt. Punkt ist, die Sprache ansich leistet das nicht, was sie sollte.
Original geschrieben von Norbert Eder
99% der Entwickler verwenden jedoch eine IDE (zumindest ist das unter Windows so) und mit HIlfe der IDE kannst Du dies feststellen.
Wenn du 2000 Zeilen Code vor dir hast, musst du mit deiner IDE entweder mit der Mouse über die Zuweisungen schweben um die Hilfe zu bekommen oder eine andere Aktion ausführen.
Das heisst mann kann den Code nicht einfach nur mit den Augen ergründen.
Original geschrieben von Norbert Eder
Properties sind hauptsächlich für UserControls gedacht. Du hast genauso die Möglichkeit reine Getter und Setter Methoden zu implementieren. Und hier kannst Du natürlich wieder feststellen ob es sich um eine Methode oder um eine Variable handelt..
Nein da irst du dich. Properties sind für Eigenschafften gedacht die von anderen Programmen durch reflection herausgefunden werden können.
Sie werden u.a in UserControls genutzt, aber nicht ausschliesslich und nicht am meisten. So nutzen einige XML Librarys und auch einige Loggin Mechanismen die Möglichkeit Properties auszulesen und anhand diesen Zustände der Objecte zu analysieren. UserControls und GUI Builder sind nur ein Teil der Programme die Properties nutzt.
Wenn ich dann unter C# get und set Methoden wie unter Java nutzen soll dann kann ich keine Properties benutzen weil eben Programme wie UML tools dies nicht als Properties verstehen. Ich würde auch nie auf die Idee kommen unter C# getBla und setBla Methoden zu nutzen da dies keine Properties sind, und so auch nicht von meinen Werkzeugen erkannt werden. Also muss ich damit leben das unter .net die Art wie Properties behandelt werden auf den 1. Blick ja ganz nett ist aber letztendlich Probleme verursacht.
Ich habe immer zugegeben das es Dinge bei C# gibt, die sie ganz nett umgesetzt haben und das besser geregelt haben wie in Java. Ok sie hatten ja viel Zeit neue Features zu entwickeln da ja 90% von Java abgeschaut worden ist ...
So ist autoboxing und foreach eine *wirkliche* Verbesserrung. Die get / set Properties unter .net sind es aber auf gar keinen Fall.
Im übrigen ist Sun ja auch nicht doof, und was von vielen als Verbesserrung empfunden worden ist wurde in 1.5 auch umgesetzt wie eben autoboxing und foreach