Kann man in Java undefiniertes Verhalten erzeugen??
-
Der Witz bei diesem Pattern ist, dass eine private Methode von einer öffentlichen Methode aufgerufen wird. In einer abgeleiteten Klasse wird dann die private Methode überschrieben, um das Verhalten im Detail zu verändern. In Java müsste man diese Methoden dann anscheinend sichtbar machen, obwohl das völlig unnötig ist. Da ich nicht wirklich den Sinn darin sehe, dass private Methoden nicht dynamisch gebunden werden (dazu gibts doch final), frage ich mich eben, was Sun sich da gedacht hat.
-
Jo, da müsste man dann die "Detail-Methode" protected machen.
Mir ist natürlich jetzt klar, dass die Kapselung mit einer virtual private Methode noch besser ist, weil die abgeleitete Klasse die Methode dann nur redefinieren aber nicht aufrufen kann.
Prinipiell gefällt mir persönlich das System von beispielsweise C# auch besser, ganz einfach auch aus Performancegründen. Die JVM inlined glaub ich weniger winzigweich-Methoden (die fast nichts machen), als mir lieb sein kann, virtual kann auch einfach eine Hilfe für den optimierenden Compiler sein.
-
Hi
@Optimizer
weis ich seitdem auch. was man nicht mehr sieht mus nicht umbedingt wirklich tot sein, sondern kann auch noch im speicher weiter vegetieren und resorcen blockieren.
Stell dir mal die situation vor, du verwendest ein Objekt von dem du nur die öffentlich Schnistelle kennst. ( wozu soll ich Interne private schnitstellen für andere documenteiren auser für mich? ich will ja schlieslich nicht alles verrathen oder) Dieses Leitest du ab um es zu erweitern. dummerweise erwischt du beim Namen deiner privaten Methoden einen der bereits im obj implementiert ist. dann wünsch ich viel spass beim fehlersuchen.
ok sie müste unter c explizit virtuell deklariert werden. in Java ist das aber leider nicht der fall.
auserdem kann das sein das du PrivatMethoden mit PrimitivMethoden verwechselst? Bei mir im Buch stand zumindestens beim überfliegen nichts davon drin primitivMethoden private zu implementieren.
gruss Termite
-
Es wird schon der Punkt sein, dass man nicht aus Versehen private Methoden redefiniert, was in 99% der Fälle wahrscheinlich nicht gewünscht ist.
Das ist eigentlich eine ziemlich gute Überlegung von dir, ich könnte mir vorstellen, dass das der Grund dafür ist, dass diese Methoden nicht dynamisch gebunden werden.Korrektur meiner obigen Aussage: Man müsste den Zugriffsschutz nicht auf protected setzen, sondern es würde package-private reichen. Was die sich mit dem protected gedacht haben, ist mir auch durch und durch ein Rätsel.
Und C# muss ja auch gleich auftrumpfen mit protected, internal, internal protected.
-
Optimizer schrieb:
Was die sich mit dem protected gedacht haben, ist mir auch durch und durch ein Rätsel.
Was meinst du?
-
Ach, das sollte nur so eine Randbemerkung sein, weil mir das bis heute unverständlich ist.
In Java ist der Zugriff auf protected Member von einer abgeleiteten Klasse und von allen Klassen innerhalb des selben namespaces aus erlaubt.
Ein Zugriffsschutz mit der Semantik von C++ oder C# - protected existiert in Java nicht.
Ich find das in C++ eigentlich gut. Mir ist nicht klar, warum die das für Java geändert haben...
-
Da es keine Zugriffsregelungen für Namespaces in C++ gibt und Packages eh was anderes sind, seh ich nicht so direkt, was da "geändert" wurde. Es gibt in Java gegenüber C++ eine neue Modularisierungsebene (package), die irgendwie in den Sichtbarkeitsmechanismus eingebaut werden muss. Nun hat man sich eben so entschieden, dass das Package "privater" ist als eine Subklasse.
Was IMHO auch nicht ganz falsch ist. Ein Package gehört physisch zusammen, man kann idR davon ausgehen, dass ein begrenzter Kreis von Programmierern an einem Package arbeitet, so dass Konflikte schnell ausgeräumt werden können. Subklassen dagegen können auch in anderen Packages liegen, d.h. dass das protected Interface der Basisklasse schon recht durchdacht und stabil sein sollte. Auch wenn die reine Zahl der Nutzer dieser Schnittstelle gegenüber der einer öffentlichen Schnittstelle kleiner sein dürfte, gibt es doch kein technisches Mittel, was sie begrenzt. Man muss also protected mit dergleichen Sorgfalt behandeln wie public.Man könnte höchstens noch argumentieren, dass protected-Elemente nicht im selben Package sichtbar sein sollten. Hat man sicher auch überlegt, aber verworfen.
-
Man könnte höchstens noch argumentieren, dass protected-Elemente nicht im selben Package sichtbar sein sollten. Hat man sicher auch überlegt, aber verworfen.
Ja, genau dieses meinte ich ja.
Überlegt hat man es sich mit Sicherheit, in Java gab es am Anfang noch 7 Zugriffsmodi zur Auswahl. Das auf 4 zu reduzieren finde ich nicht schlecht, aber irgendwie fehlt mir trotzdem die Möglichkeit, etwas für eine Subklasse anzubieten, ohne dass gleich das ganze Package da rumwurschteln kann.Den Zugriffsschutz um den package-Mechanismus zu erweitern ist ja eigentlich mit package-private schon geschehen (dem Standard halt).
Vielleicht könnte man dann noch etwas mit "package & protected" anbieten, aber dann isses genug.
Auf jeden Fall finde ich es nicht gut, den Namen "protected" für einen Zugriffsschutz zu verwenden, der das zweitöffentlichste, was überhaupt möglich ist, darstellt.
-
Moin
Sowas ähnliches kanst du ja reprosuzieren in dem du die Klassen in ein eigenes Packet verschnürst. Ist sicher nicht die eleganteste Möglichkeit. Und da du ja selber zuständig für die pakete bist kannst du ja entsprechend sortieren. (noch was worauf man achten muss )
die lösung von java hat aber auch seine Vorteile. Siehe Beispiel Template Methode. Man muss den zentral alg nicht in der basis mit implementieren sondern kann ihn in eine eigene Klasse auslagern, die im gleichen packet liegen muss wie die Basies. ggf kann die basies sogar als Interface implementiert werden. die Ableitungen der Basies bzw die Implementierung des Interfaces werden ja dann sowieso in anderen Packeten einsortiert, da sie ja erst von dritten implementiert werden.
gruss Termite
-
Optimizer schrieb:
Auf jeden Fall finde ich es nicht gut, den Namen "protected" für einen Zugriffsschutz zu verwenden, der das zweitöffentlichste, was überhaupt möglich ist, darstellt.
Das ist aber in C++ nicht anders
Ich seh einfach package visibility nicht als Öffnung an, weil ein Package immer begrenzt bleibt. Man kann sich nicht mit legalen Mitteln in ein Package injizieren.
-
Das ist aber in C++ nicht anders
rofl, verdammt.
