nicht angemeldet
Hi!
Die Unterstrichregel ist nicht sinnvoll bei als protected ausgezeichneten Mitgliedern, denn die können in einer abgeleiteten Klasse zu public umdeklariert werden und dann stünden sie da mit ihrem Unterstrich und verwirrten dich beim Codelesen.
Wenn ich SOWAS tue, habe ich sowieso Probleme mit meinem Code, nicht nur beim Lesen.
Ich hab das gerade mal ausprobiert: Funktioniert unerwarteter Weise tatsächlich - würde ich allerdings nie so realisieren.
Und ich stutzte neulich kurz darüber, dass die Sichtbarkeit in C# nicht geändert werden kann.
Wenn ich eine Klasse erweitere, und eine als protected vererbte Methode neu als public implementiere, dann bringt mir das erstmal keinerlei Vorteile, wenn ich den Namen beibehalte. Sprich: Ich kann genausogut auch einen neuen Namen vergeben, ohne Unterstrich. Denn die neue Methode ist ja einfach so aufrufbar, ohne automatisch irgendwie die vererbte Methode aufzurufen.
Die neue überschreibt aber die alte, was ja durchaus nicht unsinnig ist, wenn der alte Klassencode diese Methode anspricht und nun auf meiner neuen, erweiterten/geänderten/korrigierten landen soll. Ansonsten hätte ich in dem Fall zwei Methoden, eine neue unterstrichlose mit der neuen Implementation und eine alte, die den Code der neuen aufruft. Das wird am Ende nicht weniger verwirrend als der falsch gewordene Unterstrich.
Und der Zugriff auf die vererbte Methode ist in beiden Fällen mittels parent:: möglich, es kommt also nicht zwingend darauf an, dass die neue Methode den gleichen Namen besitzt.
Nur wenn man sich innerhalb der Klasse befindet. Von außen geht parent:: natürlich nicht. Irgendwie finde ich das nicht gerade clever, wenn der alte Klassencode _foo() nimmt und ein darauf aufbauendes Projekt foo() verwendet. Kann man dem "alten" Programmierer zum Vorwurf machen, dass er nicht vorausgesehen hat, dass der "neue" die betroffene Funktionalität anders und nun öffentlich haben möchte?
Lo!