Vererbung protected NUR für Unterklassen?

[KaPiChu]

Hallo!
Mein Problem ist ganz einfach: mich stört es, dass der protected-modifer auch für alle Klassen im gleichen Package sichtbar sind. Das stört aber, da ich meistens abstrakte Basis-Klassen definiere, die Eigenschaften haben, die NUR für deren Unterklassen sichtbar sein sollen. Gibt es da vielleicht irgendein Trick oder so was? (Also jetzt nicht ein Java-Hack oder so 😀)

 

[KSG9|sebastian]

Ne, protected ist für Subklassen und im selben Package sichtbar, da führt kein Weg daran vorbei.

Es gibt nur
default - selbes Package
public - überall
protected - selbes Package + Subklassen
private - Klasse

 

[KaPiChu]

Och menno. ;(
Hat das denn irgendeinen Sinn protected auch für alle Klassen im selben Package zuzulassen?

 

[Michael...]

Hat das denn irgendeinen Sinn protected auch für alle Klassen im selben Package zuzulassen?

Welchen Sinn hätte es denn Deiner Meinung nach wenn dem nicht so wäre bzw. wenn es eine Möglichkeit gibt Methoden ausschließlich für die Klasse und deren Subklassen sichtbar zu machen?

 

[KSG9|sebastian]

Was findest du denn daran so schlimm?
Der Namensraum gehört doch sowieso dir, ist ja nicht so das da jemand drin rumpfuscht von Extern...außer über "Hacks"..

 

[SlaterB]

Welchen Sinn hätte es denn Deiner Meinung nach wenn dem nicht so wäre bzw. wenn es eine Möglichkeit gibt Methoden ausschließlich für die Klasse und deren Subklassen sichtbar zu machen?

das ist doch gleichbedeutend zum Sinn von Vererbung überhaupt,
wenn X von Y erbt dann kann Y mit einigen internen Methoden und Attributen von X was anfangen, welche nach außen nicht sichtbar sein müssen

dagegen ist package ein recht loser Verbund, wie viele Projekte auf der Welt bestehen nur aus wenigen packages, maximal z.B. nach Daten/ Logik getrennt, nicht nach Interaktion der Klassen untereinander (*)

also dass package wenig zu sagen hat, aber bei Vererbung Zugriff benötigt wird, das erlebe ich quasi jeden Tag so und kann mich über die Zugriffsmodifikatoren von Java auch nur wundern,

na es gibt ja immerhin funktionierendes protected, viele Klassen nach außen sehen nichts,
allerdings: (*) Zugriff im gleichen package, so unterschiedlich Logik-Klassen X und Y auch sind, gibt es dennoch und dann schade um nicht vorhandenen Sichtbarkeitsschutz

 

[Network]

@Michael & KSG9
Naja wenn es sich um ein Projekt einer größeren Gruppe handelt könnte es definitiv zu einer Fehlfunktion des Programmes kommen, wenn mal jmd. unscheinbar eine Methode im falschen Moment aufruft.
Was natürlich gleichzeitig auch ein Zeichen schlechter Planung, Dokumentation und schlussendlich Programmierung ist.
Stimme aber zu, dass es einen only subclasses modifier geben sollte bzw. es wäre manchmal nicht schlecht.

Schlussendlich musst du deine Methoden so aufbauen, dass du überprüfen kannst ob der Aufruf der Methode selbst zu diesem Zeitpunkt, unter diesen Umständen legal war.
Und das sollte man so oder so tun (protected hin oder her) wenn es die Stabilität des Programmes beeinflussen kann.

Gruß
Net

PS: Soweit ich weiss gibt es keine Sprache die protected so (schlecht) verwendet wie Java.

*Edit: @SlaterB dem kann ich nur zustimmen

 

[Timothy Truckle]

wie viele Projekte auf der Welt bestehen nur aus wenigen packages,

Da machen wir also aus den Fehlern der Anwender gleich mal einen Fehler der Sprache?

Ich brauch den package-private Zugriff zB. für Unittests von Methoden, die ich andernfalls public deklarieren müsste um sie aus dem Test heraus aufrufen zu können...

bye
TT

 

[SlaterB]

es spricht ja absolut nichts dagegen, AUCH package-Sichtbarkeit anzubieten, wenn benötigt,
aber das ist doch eher eine Seltenheit, wobei z.B. Unittests nicht gerade ins normale OO-Bild gehören,
und selbst bei JUnit primär doch wohl das öffentliche Interface, die public-Methoden, als Testeinheiten zu sehen sind

ich meine z.B. das package javax.swing (soviel zu Fehler der Anwender..),
alle Textfelder, alle Buttons, alle ScrollPanes, alle ProgressBar usw. liegen zusammen,
wäre ja auch irre dafür unterschiedliche packages anzulegen, und es gibt schon nicht zu knapp

wieso muss ein JTextField Details sehen, die ein AbstractButton vielleicht an seine erbenden Buttons gedacht hat?

 

[nillehammer]

Im Gegensatz zu einigen meiner Vorposter fehlt mir das Problembewusstsein. Alles, was in einem Package ist, gehört in einer Art und Weise zusammen, dass ich es nicht vor gegenseitigen Zugriffen geschützt werden muss (außer natrürlich GANZ private Sachen, für die es ja auch private gibt). Insofern habe ich kein Problem damit, dass protected die Package-Sichtbarkeit einschließt. Man darf nicht vergessen, dass es bei Sichtbarkeiten nicht um Zugriffsschutz im Sinne von IT-Sicherheit geht, sondern um Schutz vor zu enger Koppelung und unorganisierten Abhängigkeiten.

 

[SlaterB]

Alles, was in einem Package ist, gehört in einer Art und Weise zusammen, dass ich es nicht vor gegenseitigen Zugriffen geschützt werden muss

siehe auch mein vorheriges Posting zu javax.swing oder z.B. Hibernate jar:
im Basis-package org.hibernate finden sich so unterschiedliche Klassen wie
LockMode, CallableException, Criteria, Query, Session, Transaction, Filter, ScrollableResults, usw.

oftmals nur einzelne Klassen, teils so wichtig, dass sich Unterpackages wie org.hibernate.criteria durchaus lohnen würde, gar zu vermuten wäre, aber wo passiert das schon?
ob Logger, JBDC-Treiber, Commons oder Java-API, es gibt immer ~100 Klassen und 10 packages,
und dabei vermeidbar offene Sichtbarkeit

ein Schutz bis hin zu private ist nie ernsthaft nötig, aber doch wünschenswert allein zur Komplexitätsverringerung, ausblenden was nicht zum öffentlichen Interface gehört

 

[Timothy Truckle]

es spricht ja absolut nichts dagegen, AUCH package-Sichtbarkeit anzubieten, wenn benötigt,

Stimmt, haben wir aber nicht. Die Frage ist, ist es wirklich ein Problem?
Für mich nicht...

und selbst bei JUnit primär doch wohl das öffentliche Interface, die public-Methoden, als Testeinheiten zu sehen sind

Als Testeinheit ja, aber für mich haben sich package private getter als praktische Möglichkeit erwiesen, unkompliziert Mock-Objekte in die zu testende Klasse einzuschleusen.

bye
TT

 

[nillehammer]

siehe auch mein vorheriges Posting zu javax.swing oder z.B. Hibernate jar:
im Basis-package org.hibernate finden sich so unterschiedliche Klassen wie
LockMode, CallableException, Criteria, Query, Session, Transaction, Filter, ScrollableResults, usw.

Deine Beispiele für ein wohl schlechtes Package-Design sind aber troztdem kein Argument dafür, warum es ein Problem ist, wenn Klassen im selben Package die protected Methoden/Felder von anderen Klassen sehen.

 

[SlaterB]

demnach nutzt also Hibernate Java falsch? die Java-Api nutzt Java falsch?
gibt es irgendeine Library mit 100 Klassen, welche anscheinend 40 statt 10 packages verwendet, die man eben braucht?
scheint mir etwas vermessen im Anspruch 😉

 

[...ButAlive]

Ich seh das Problem nicht. Solange es in meiner Verantwortung liegt, und das tut es wenn die Klassen in einem Package sind, muss ich dafür sorgen das alles in Ordnung ist. Das tut man in der Regel mit Hilfe von Unit-Tests.

Durch das "Seperation of Concerns"-Prinzip gibt es Fälle, in denen es Sinn macht, dass eine Funktionalität von Klasse A in Klasse B ausgelagert werden muss und die Klasse B Zugriff auf Werte von Klasse A braucht. Um die Kappselung von Klasse A nicht vollkommend aufzugeben, legt man Klasse B in das selbe Package und setzt den Modifier auf package private. Ich sehe dabei kein Problem, package private hat für mich durchaus Sinn, sonst bekäme man eine Gottklasse die zu viel macht.

Auch protected macht Sinn. Da in Java "package private" kein Modifier bedeutet, wäre es ein rießen Problem, wenn protected "NUR für Unterklassen" bedeuten würde, denn so könnte man nie die Vorteile von "package private" für protected Felder nutzen.

 

[Network]

Das Thema driftet an.
- Die großteil sagt "Oh nein bitte kein zusätzlichen 'only subclasses' weil ich nutze protected" (?!)
- Der Rest sagt (Und damit meine ich SlaterB) ein zusätzlicher Modifier wäre nicht schlecht der dieses Aufgabe absteckt.

Schlussendlich führt die ganze Diskussion hier zu nichts. Weil selbst wenn eine Partei es schaffen sollte alle anderen zu überzeugen dann... was?
Die Antwort für den Fragesteller bleibt in jedem Falle: Nein. Das geht nicht.

Gruß
Net

PS: Ich kenne mich mit Annotiationen nicht so perfekt aus. Aber wenn @Override kontrollieren kann, dass ein Codeteil ungültig wird wenn etwas nicht wirklich überschrieben wird, könnte man dann nicht auch eine Art eigenen Modifier so einführen?
Oder ist das eine Spezialannotation die man nicht nachprogrammieren kann?

 

[tröööt]

ich hab mir mal alles durchgelesen und finde die diskusion recht interessant ...

klar müsste man TO erstmal sagen : NEIN, so einfach wird es wohl nicht gehen ...
wobei ich mir sicher bin das es irgendwie schon möglich sein könnte ... vllt mit umweg über JNI und callbacks oder annotations ... kann mir nicht vorstellen das es komplett unmöglich sein sollte ... aber es dürfte trotzdem sehr aufwändig werden ...

ansonsten zur diskusion

sehen wir uns doch mal folgende tabelle an : Controlling Access to Members of a Class (The Java™ Tutorials > Learning the Java Language > Classes and Objects)

so sehen wir das es 4 access level gibt und dazu auch 4 modifier ...

würde man jetzt einen weiteren modifier einfügen der nur CLASS und SUB-CLASS ... nicht aber PACKAGE ermöglichen würde ... würde man DAMIT eigentlich eher gegen die verwendung der access-modifier fahren als wenn man behauptet das die aktuelle verwendung falsch wäre ...

denn java definiert PACKAGE nun mal als "kleineren" scope als PACKAGE+SUB-CLASS ...

in wie fern das nun sinn macht ... und wie es in anderen sprachen umgesetzt wurde ... und in wie weit man daran bemessen kann wie gut oder schlecht seine modifier implementiert hat ... das wäre eine andere diskusion wert ...

fakt ist jedoch : von den java-entwicklern wurde diese struktur so festgelegt ...


das es nicht immer unbedingt günstig ist wenn zwei klassen die an sich nichts mit ein ander zu tun haben aber trotzdem im selben package liegen ihre protected-member sehen können ... ja gut ... mag sein ... allerdings fand ich den einwand gut : so lange sich die klassen in meinem package befinden trage ich die verwantwortung dafür das sich da nichts in die haare kommt ... und ich denke desshalb ist es zu vernachlässigen ... weil jeder entwickler selbst die kontrolle über seine packages hat ...

klar gibt es immer wieder spezialisten die trotzdem versuchen gegen alles und jeden sturm zu laufen ... aber entsprechend der architetkur hat die aufteilung so wie es ist schon ihren sinn ...

 

[SlaterB]

denn java definiert PACKAGE nun mal als "kleineren" scope als PACKAGE+SUB-CLASS ...

nicht dass die Einhaltung der lustigen Tabelle besonders wichtig wäre, aber es wäre möglich:
der 'no modifier' müsste sich allein auf Subklassen beziehen, nicht auf packages

dass man Zugriff im package haben will ist selten, aber schön und gut, dafür kann man dann protected nehmen,
aber es ist doch irrwitzig, zusätzlich 'nur package ohne Subklassen' einzuführen, viel gebräuchlicher wäre 'nur Subklassen ohne package'

wofür gibt es das absolut zentrale Konzept von Vererbung, Interfaces, Polymorphie, Klassen?
das ist DAS wesentliche Element von Objektorientierung überhaupt,
packages ist im Vergleich eine unerhebliche zusätzliche Spielerei,
die keine OO-Lehrveranstaltung auf ähnlichem Level erwähnen würde

dass Ober- und Unterklasse zusammenarbeiten, etwas 'gemeinsam aushecken' welches nach außen nicht sichtbar sein sollte, ist 100x wichter/ wahrscheinlicher/ normaler, als dass mehrere Klassen in einem package zusammenarbeiten, eine Einheit bilden,
natürlich gibt es das, natürlich ist protected sinnvoll, aber 'no modifier' ist verhunzt, muss sich auf Subklassen ohne package beziehen

ein richtiges Argument habe ich dagegen hier noch nicht gehört,
'ist ja nicht so wichtig, wer braucht schon Kontrolle?' erinnert mich eher an Fr. Schavan,

Zuspitzung wäre:
"wozu gibt es eigentlich private?
kann man auch abschaffen, mindestens im package können alle untereinander alles sehen,
allein nach außerhalb des package Kontrolle, denn package ist die große Grenze der OO, nicht Klassen,
es braucht nur noch protected oder public"
??


edit:
so, wenn es sonst keiner deutlich erklären wollte dann musste ich selber ebenfalls die Gegenposition übernehmen 😉 ,
das Schaubild im Link hilft: APIs sind im Idealfall erweiterbar, man kann aus dem Originalpackage herausgerissen eine Subklasse bilden,
dies ist ein Fremdling gegenüber der gesamten API, gegenüber dem package,
sollte nicht unbedingt all die internen Details sehen, die innerhalb des packages beim gegenseitigen Zugriff benötigt werden

unter dieser Sichtweise ist das package eine engere Struktur als die Vererbung, damit ist die Wahl der Modifiert verständlich,
nicht eindeutig sicher ob besser oder schlechter, aber eine Wahl, deren Hintergrund man verstehen/ akzeptieren kann

wenn man die 4 Stufen beibehalten will, vielleicht technisch vorteilhaft,
dann ist für 'nur Subklassen ohne package' kein Platz da,
wenn man nicht ganz restrikiv wäre, hätte das auch seinen Einsatzzweck