Kann man in Java undefiniertes Verhalten erzeugen??
-
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.
