Abstrakte Klasse erwweitern

[Guest]

Hallo!

Hab da eine Frage zu abstrakten Klassen und deren Verwendung. Es geht dabei hauptsächlich um die Verwendung im "objektorienierten" Sinn.

1. Macht eine abstrakte Klasse ohne abstrakte Methode Sinn?

2. Wenn man in (algemeinen oder abstrakt) Klaasen Variablen deklariert sollte man dann in der Subklasse darauf zugreifen können. Also ohne getter und setter. Oder sollte man die Variablen immer private machen, sodass sie auch in der Subklasse nicht direkt verwendet werden kann?

 

[stevieboy]

1. Macht eine abstrakte Klasse ohne abstrakte Methode Sinn?

Wozu soll das gut sein? Ich kann mir gerade keine sinnvolle Verwendung dafür vorstellen.

2. Wenn man in (algemeinen oder abstrakt) Klaasen Variablen deklariert sollte man dann in der Subklasse darauf zugreifen können. Also ohne getter und setter. Oder sollte man die Variablen immer private machen, sodass sie auch in der Subklasse nicht direkt verwendet werden kann?

Wenn Du mit Subklasse eine Klasse meinst, die von einer anderen erbt, dann erbt sie die privaten Variablen usw. nicht.

Es ist imho nicht sinnvoll, auf Attribute (Variablen) direkt zuzugreifen. Dies macht nur bei Konstanten Sinn und diese sollten dann auch public definiert werden.

 

[maki]

1. Macht eine abstrakte Klasse ohne abstrakte Methode Sinn?

Wenn man nur einen "Platz" braucht um Konstanten zu definieren, dann ja, ist aber eher selten.

Nachtrag: Denkbar sind auch abstrakte Klasen, welche nur statische Methoden haben.

2. Wenn man in (algemeinen oder abstrakt) Klaasen Variablen deklariert sollte man dann in der Subklasse darauf zugreifen können. Also ohne getter und setter. Oder sollte man die Variablen immer private machen, sodass sie auch in der Subklasse nicht direkt verwendet werden kann?

imho sollten diese Variablen als protected deklariert werden, auf die eigenschaften einer Superklasse per get und set zuzugreifen ist imho nicht wirklich sinnvoll.

Als Beispiele kannst du dir ja mal AbtractList, AbstractSet und AbstractCollection der Java API ansehen.

 

[byte]

Eine abstrakte Klasse ohne abstrakte Methoden macht dann Sinn, wenn man einfach verhindern möchte, dass eine Klasse als Objekt instanziert wird. Die Standard API ist voll von sowas.

 

[tfa]

Eine abstrakte Klasse ohne abstrakte Methoden macht dann Sinn, wenn man einfach verhindern möchte, dass eine Klasse als Objekt instanziert wird. Die Standard API ist voll von sowas.

Ich halte das für zweifelhaft. Um Objekterzeugung zu verhindern kann man den Default-Konstruktor private machen (und die Klasse als final deklarieren).
Abstrakte Klassen ohne abstrakte Methoden sind meiner Meinung nach nicht sinnvoll.

 

[Marco13]

Wenn Du mit Subklasse eine Klasse meinst, die von einer anderen erbt, dann erbt sie die privaten Variablen usw. nicht.

Äh - sie erbt sie schon, darf aber nicht darauf zugreifen....

1. Macht eine abstrakte Klasse ohne abstrakte Methode Sinn?

Ja, und byto hat schon gesagt, warum.
(@tfa: Diese Klasse könnte man dann ja überhaupt nicht mehr instantiieren.)
Eine abstrakte Klasse ohne abstrakte Methoden macht (etwas präziser gesagt) dann Sinn, wenn man nicht Objekte dieser Klasse erstellen können will, sondern nur Objekte von Klassen, die von dieser (abstrakten) Klasse erben.

EDIT:

Nachtrag zu Punkt 2.: Dort können protected-Variablen häufig sinnvoll sein. Allerdings spricht i.a. nichts dagegen, sie private zu machen, und etwa eine "public" get-Methode und eine "protected" set-Methode anzubieten oder so...

 

[maki]

Nachtrag zu Punkt 2.: Dort können protected-Variablen häufig sinnvoll sein. Allerdings spricht i.a. nichts dagegen, sie private zu machen, und etwa eine "public" get-Methode und eine "protected" set-Methode anzubieten oder so...

Doch, da gibt es Dinge die dagegen sprechen.

Auf eine public Methode dürfen alle zugreifen, nicht nur die Klasse die erbt.
Manchmal sollen wirklich nur erbende Klassen darauf zugreifen können, zB. um das verhalten der Implementierung der Abstracten Klassen zu verändern/beizubehalten, als Beispiel siehe dazu das modCount feld der AbstractList.

Wenn die Eigentschaft public sein soll, sollten natürlich auch die Methoden public sein, allerdings ist das nicht immer der Fall und protected ist sehr nützlich im Zusammenhang mit Vererbung

 

[tfa]

(@tfa: Diese Klasse könnte man dann ja überhaupt nicht mehr instantiieren.)

Selbstverständlich kann man das. In der Klasse selbst. Singletons machen soetwas andauernd. Aber es ging doch darum zu verhindern, Objekte anzulegen?!

Wenn man trotzdem noch von der Klasse Ableitungen erzeugen will aber eben keine konkreten Objekte, macht man den Konstruktor halt protected (OK, im Package sind dann immer noch Objekte möglich).

 

[byte]

Ich halte das für zweifelhaft. Um Objekterzeugung zu verhindern kann man den Default-Konstruktor private machen (und die Klasse als final deklarieren).
Abstrakte Klassen ohne abstrakte Methoden sind meiner Meinung nach nicht sinnvoll.

Kannst Du private Konstruktoren denn noch in Unterklassen aufrufen?

 

[tfa]

Kannst Du private Konstruktoren denn noch in Unterklassen aufrufen?

Nein (s.o.). Ich dachte, Du wolltest gar keine Objekte zulassen, wie z.B. in java.lang.Math.

 

[Marco13]

Wenn die Klasse abstract sein sollte, kann man ja davon ausgehen, dass davon geerbt werden soll (genau das soll ja mit dem abstract-sein erzwungen werden!). D.h. die Nachfolger könnten die Klasse nichtmehr instantiieren. Dass die Klasse als Singelton oder Factory sich selbst instantiieren könnte, ist klar.

 

[happy_robot]

1. Macht eine abstrakte Klasse ohne abstrakte Methode Sinn?

Wozu soll das gut sein? Ich kann mir gerade keine sinnvolle Verwendung dafür vorstellen.

Grundsätzlich macht eine abstrakte Klasse, auch wenn sie keinerlei abstracts hat, so viel Sinn wie ein Interface welches nicht implementiert wird

Wenn ich ausschliesslich ohne grossen Aufwand Spezialisierungen meiner Klasse zulassen will macht das aber schon Sinn. Der bessere und sauberererererere Weg wären hier aber sicherlich protected-Konstruktoren.

Is' aber auch ne dolle Variante wenn man die direkten Referenzen mal durchforsten will und nur den comiler zur verfügung hat. "abstract" davor und schon sagt's einem der comiler