abstract, privat, Vererbung

[OOP-ler]

Hallo, folgendes Problem:
Ich möchte eine Klasse machen, worin sich eine abstrakte Methode befinden, die am besten privat sein soll, sprich wenn eine Klasse von dieser Grundklasse erbt, soll es diese Methode überschreiben, aber diese soll dann privat sein. Aber natürlich geht dies nciht, da der java compiler dann ein Fehlermeldung auswirft... Aber wie kann man nun mein Vorhaben realisieren ? Wenn ich protected nehme, dann können ja theoretisch Klassen im selben Paket auf diese Funktion zugreifen, was ich aber ganz gern verhindern würde.... Wie macht man daS ?=

Gruß Ralf

 

[0x7F800000]

Hallo, folgendes Problem:
Ich möchte eine Klasse machen, worin sich eine abstrakte Methode befinden, die am besten privat sein soll, sprich wenn eine Klasse von dieser Grundklasse erbt, soll es diese Methode überschreiben, aber diese soll dann privat sein.

so sind die schlüsselwörter nun mal nicht gedacht, private garantiert nur, dass niemand ausserhalb der klasse die methode verwenden darf, und abstrakt garantiert, dass die klasse selbst die methode auch nicht aufrufen kann, weil diese ja nicht implementiert ist. Also kann man nirgendwo die methode aufrufen, deswegen lässt der kompiler das verständlicherweise nicht zu, weil es nicht viel Sinn macht. :bahnhof: wie bist du denn in so eine Situation geraten, wozu soll dein vorhaben in etwa gut sein?

 

[OOP-ler]

Wieso könnte ich darauf nciht zugreifen ?
Ich verstehe nciht, warum Java das hier nicht zulässt:

	static abstract class Blub
	{
		abstract privat void Neutral(); 
	}
	
	static class Blub2 extends Blub
	{
		private void Neutral()
		{
			
		}
	}

Das geht natürlich nicht, weil man keine privaten MEthoden erben kann, aber dass ist doch ziemlich doof, wenn man eine abtrakte Methode garantiert haben will, die von niemanden außer dieser Klasse selbst aufgerufen werden kann !
Oder verhaspel ich mich jetzt ?!

Gruß Ralf

 

[OOP-ler]

Oh sry, noch was vergessen: Ich meinte natürlich von niemand anders, als abgeleiteten Klassen, eine Sichtbarkeitsvariable, die das bezweckt fände ich gut !

 

[musiKk]

Für abgeleitete Klassen (und Klassen im selben Package) gibt es protected. Auf private Methoden können auch abgeleitete Klassen nicht zugreifen.

 

[OOP-ler]

Dann haben die einfach was vergessen xD Ne mal im Ernst, ist mein Vorhaben denn so selten ? Ich finde das total legitim, dass man garantieren will, dass eine bestimmte methode nur in der Herachie einer Klasse verfügbar ist...

Gruß Ralf

 

[musiKk]

Ja, dazu benutzt man protected...

 

[OOP-ler]

Nein ! Bei protected können auch andere Klassen des selben Pakets auf diese Methode zugreifen, ist jetzt in meinem Fall ok, aber bei anderen Situationen ist auc hdas nicht zufrieden stellend, das finde ich fehlt der Sprache Java... Aber auch den anderen Sprachen...

Gruß Chris

 

[musiKk]

Ich finde, das reicht so, aber das ist mal wieder Geschmackssache. In C++ kann man das granularer einstellen.

 

[0x7F800000]

da muss es doch irgendwo einen knick in der logik geben... wenn du das vorhandensein dieser methode zur privatsache der unterklassen erklärst, dann ist es doch absurd, eine solche methode allen unterklassen aufzuzwingen.

wie soll denn etwas privat sein, wenn es von der super klasse diktiert wird? das ist doch ein widerspruch an sich :roll:

 

[Loep]

Protected Methoden können doch NUR von abgeletiteten Klassen genutzt werden, oder? Auch Klassen des selben Package können dies nicht, dazu wäre der Package Scope (sprich kein Marker vorm Namen) notwendig.
Oder hab ich da was falsch verstanden?

 

[musiKk]

Ja.

protected - An access modifier used in a method, field or inner class declaration. It signifies that the member can only be accessed by elements residing in its class, subclasses, or classes in the same package.

 

[ARadauer]

[qoute] or classes in the same package.[/qoute]
finde ich persönlich nicht schön, mir wärs lieber gewesen wenn für das ein eigenes schlüsselwort eingeführt worden wäre...

 

[tfa]

or classes in the same package.

finde ich persönlich nicht schön, mir wärs lieber gewesen wenn für das ein eigenes schlüsselwort eingeführt worden wäre...

Ich finde, es gibt schon genug Schlüsselworte. Und braucht man so eine feine Unterscheidung in der Praxis wirklich? Ich fände es nicht mal schlimm, wenn es nur public und private gäbe. Einige Sprachen (z.B. Smalltalk und Objective C) kennen Zugriffsmodifikatoren überhaupt nicht. Da sind alle Methoden öffentlich und trotzdem kann man damit programmieren.

 

[0x7F800000]

ja, sicher, wenn man zurechnungsfähig ist, kann man damit sicherlich vernünftig programmieren. Aber dann kann schneller etwas schief gehen, wenn jemand, der keinen Plan hat, irgendetwas damit anstellt. Und dann werden von der IDE haufenweise methoden angezeigt, die einen draußen eigentlich nicht interessieren, das könnte auch nerven. Diese wörtchen machen die Sprache ja nicht mächtiger, sondern ein wenig verständlicher und übersichtlicher, und gerade wegen der übersichtlichkeit ist java ja so beliebt. Aber eigentlich gibt's schon genug schlüsselwörter, auch wenn's zu UML nicht ganz passt.

 

[Landei]

Ich denke, du hast ein grundsätzliches Verständnisproblem - nicht darüber, wie die Modifier arbeiten, sondern wozu sie gedacht sind. "private" heißt, dass dieser Teil der Klasse ein Implementierungsdetail ist, das niemanden anderes etwas angeht. "Private" ist deine Garantie, das keine Information nach außen dringt. Und dazu brauchst du keine anderen Klassen zu durchsuchen, wenn du "private" in deinem Quellcode hast, ist dieses Stück "sicher" (wenn man mal von Reflection-Zauberei absieht). Nun nehmen wir mal an, dein Anfangsbeispiel wäre erlaubt. Dann könnte ein böser, böser Mensch deine Basisklasse Blub ändern, z.B. indem er eine public Methode einfügt, die Neutral() aufruft. Das würdest du dann nicht mitbekommen (insbesondere, wenn Blub in einer Bibliothek liegt) und dein Neutral() wäre dann alles andere als privat - *jede* Klasse könnte es auf einmal (wenn auch indirekt) aufrufen.
Soll heißen: Sobald *irgendeine* andere Klasse (ob Basisklasse, Unterklasse, selbes Package) auf deine Members zugreifen kann, ist das Member einfach nicht mehr "private". Wenn die Basisklasse von der Methode wissen muss, brauchst du protected. Was du allerdings machen kannst, wäre Netral() in Blub2 als protected final Neutral() zu definieren - damit könnten Unterklassen deine Implementierung nicht mehr überschreiben.

 

[Leroy42]

ja, sicher, wenn man zurechnungsfähig ist, kann man damit sicherlich vernünftig programmieren. Aber dann kann schneller etwas schief gehen, wenn jemand, der keinen Plan hat, irgendetwas damit anstellt.

Jemand der keinen Plan hat, sollte aus meiner Sicht gar nicht programmieren!

 

[The_S]

Jemand der keinen Plan hat, sollte aus meiner Sicht gar nicht programmieren!

Ich wusste gar nicht, dass du deinen Job wechseln willst *SCNR* !?

 

[Landei]

Jemand der keinen Plan hat, sollte aus meiner Sicht gar nicht programmieren!

Genau! Der gehört ins Management!!!

 

[0x7F800000]

Ich wusste gar nicht, dass du deinen Job wechseln willst *SCNR* !?

Stellt euch vor, alle jemals erschaffene private Hilfsmethoden werden plötzlich sichtbar.
Dann habt ihr auf einmal auch keinen Plan was los ist und wozu ihr den ganzen mist eigentlich braucht und ob ihr das überhaupt braucht, oder ob das als hilfsfunktion gedacht war, die nicht von anderen verwendet werden soll. Da werden alle ganz schnell zwar nicht den job, dafür aber die sprache wechseln wollen.

aber das argument mit IDE's, die mir eine dreimal so lange liste an methoden anbieten würden, als nötig, das war eigentlich wichtiger als das argument mit "plan" usw...

 

[Yzebär]

Bei protected können auch andere Klassen des selben Pakets auf diese Methode zugreifen

Wenn dies nicht gewünscht ist, sollte man sich fragen, warum die Klassen innerhalb desselben Pakets liegen.

 

[tfa]

Bei protected können auch andere Klassen des selben Pakets auf diese Methode zugreifen

Wenn dies nicht gewünscht ist, sollte man sich fragen, warum die Klassen innerhalb desselben Pakets liegen.

Weil man nicht für jede Klasse ein eigenes Package anlegen möchte...?

 

[Saxony]

Hehe,

ja 12 Klassen in 10 Packages oder so!

bye Saxony

 

[The_S]

Lieber 10 Klassen in 12 packages :shock:

 

[0x7F800000]

das ist ja wie in dem blöden alten Witz mit zehn kindern in einer mülltonne^^ :roll:

 

[The_S]

... oder ein kind in 10 mülltonnen ...

ich find den Klasse

 

[diggaa1984]

der is mir neu, wie geht der :roll:

 

[The_S]

Steht bestimmt schon in der Witzeecke ... Aber für dich nochmal (auch wenn er ja eigentlich schon dasteht):

Was ist gemein?

Zehn Kinder in einer Mülltonne.

Und was ist noch viel gemeiner?

Ein Kind in zehn Mülltonnen.

 

[diggaa1984]

kurz und präzise ... so mit fröhlichem gemüt nun in die prüfung rennt :### ???:L :meld: :wink:

 

[The_S]

Viel Erfolg!