C/C++ Forum :: Subklasse: abstrakte Methode implementieren und privatisieren

xindon Mitglied 20:21:30 03.02.2010 Titel:

Hallo,

ich habe folgende Situation:

Eine abstrakte Basisklasse, die eine abstrakte Methode deklariert, die von der erbenden Subklasse definiert werden soll.

Doch soll diese Methode von nun an privat sein, das heißt eine weitere Subklasse, die die oben genannte Subklasse erweitert, darf die Methode nicht mehr sehen.

Wie kann ich das mit Java Sprachmitteln realisieren?

Vielen Dank schonmal :-)

Gruß,
Tim

Unregistrierter

wenn ich dich richtig verstanden habe ist das ein weg:

Java Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	abstract class AbstractBase { abstract void foo(); } class AbstractSub extends AbstractBase { @Override final void foo() { } } class AbstractSub2 extends AbstractSub { @Override void foo() // error, darf nicht mehr überschrieben werden { } }

Java Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	abstract class AbstractBase { abstract void foo(); } class AbstractSub extends AbstractBase { @Override final void foo() { } } class AbstractSub2 extends AbstractSub { @Override void foo() // error, darf nicht mehr überschrieben werden { } }

Java Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21	abstract class AbstractBase { abstract void foo(); } class AbstractSub extends AbstractBase { @Override final void foo() { } } class AbstractSub2 extends AbstractSub { @Override void foo() // error, darf nicht mehr überschrieben werden { } }

Nexus Mitglied 02:10:45 04.02.2010 Titel:

xindon schrieb:

Doch soll diese Methode von nun an privat sein, das heißt eine weitere Subklasse, die die oben genannte Subklasse erweitert, darf die Methode nicht mehr sehen.

Die Frage ist, ob dieses Vorgehen überhaupt sinnvoll ist. In Java gibts ja nicht sowas wie private Vererbung, somit kann man ein Objekt immer in den Basisklassentypen konvertieren. Folglich wäre es jederzeit möglich, über die Referenz der Basisklasse doch noch die Methode aufzurufen, selbst wenn diese zwischendurch privat gemacht werden könnte.

Java Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	abstract class AbstractBase { public abstract void foo(); } class Base extends AbstractBase { // nehmen wir an, wir könnten foo() tatsächlich privat machen. private void foo() { // ... } } // Abgeleitete Klasse: soll foo() nicht mehr sehen. class Derived extends Base { void accessFoo() { // Geht nicht, da privat. Alles okay soweit. foo(); // Geht aber über Basisklassen-Umweg. // AbstractBase.foo() ist schliesslich public. AbstractBase hacker = this; hacker.foo(); } }

Java Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	abstract class AbstractBase { public abstract void foo(); } class Base extends AbstractBase { // nehmen wir an, wir könnten foo() tatsächlich privat machen. private void foo() { // ... } } // Abgeleitete Klasse: soll foo() nicht mehr sehen. class Derived extends Base { void accessFoo() { // Geht nicht, da privat. Alles okay soweit. foo(); // Geht aber über Basisklassen-Umweg. // AbstractBase.foo() ist schliesslich public. AbstractBase hacker = this; hacker.foo(); } }

Java Code:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28	abstract class AbstractBase { public abstract void foo(); } class Base extends AbstractBase { // nehmen wir an, wir könnten foo() tatsächlich privat machen. private void foo() { // ... } } // Abgeleitete Klasse: soll foo() nicht mehr sehen. class Derived extends Base { void accessFoo() { // Geht nicht, da privat. Alles okay soweit. foo(); // Geht aber über Basisklassen-Umweg. // AbstractBase.foo() ist schliesslich public. AbstractBase hacker = this; hacker.foo(); } }

Die Frage ist also eher, durch welches Design du dich zu so einem Schritt gezwungen fühlst.

Zeus Mitglied 09:47:53 04.02.2010 Titel:

xindon schrieb:

Hallo,

ich habe folgende Situation:

Eine abstrakte Basisklasse, die eine abstrakte Methode deklariert, die von der erbenden Subklasse definiert werden soll.

Doch soll diese Methode von nun an privat sein, das heißt eine weitere Subklasse, die die oben genannte Subklasse erweitert, darf die Methode nicht mehr sehen.

Wie kann ich das mit Java Sprachmitteln realisieren?

Vielen Dank schonmal :-)

Gruß,
Tim

Garnicht und geht auch in keine andere Sprache. Wenn du eine Basisklasse die Methoden deklariert, muss man diese Implementieren mit ihren Schutzattribute.

xindon Mitglied 10:51:39 04.02.2010 Titel:

Nexus schrieb:

Folglich wäre es jederzeit möglich, über die Referenz der Basisklasse doch noch die Methode aufzurufen, selbst wenn diese zwischendurch privat gemacht werden könnte.

Das ist ein sehr guter Punkt!

Nexus schrieb:

Die Frage ist also eher, durch welches Design du dich zu so einem Schritt gezwungen fühlst.

Die Situation ist wie folgt (es handelt sich um eine kleine 3D-Engine):
Die abstrakte Klasse Application, die das Grundgerüst der Anwendungen, die meine Engine benutzen wollen, darstellt.

Davon eine abstrakte Subklasse LWJGLApplication, die bestimmte Methoden von Application überschreibt und eben in LWJGL implementiert.

Um jetzt eine Anwendung zu erstellen, die meine Engine mit LWJGL benutzt, muss lediglich LWJGLApplication erweitert werden.
Das sieht dann so aus: http://pastebin.com/m6a515499

Jetzt definiert die abstrakte Basisklasse einige Methoden, die zwar von LWJGLApplication implementiert werden müssen, aber in der Subsubklasse vom Anwender unbedingt unsichtbar sein müssen. (zB destroyLibrary(), was Application aufruft und von LWJGLApplication implementiert wird).

Hab aber auch schon eine Idee, wie ich's umstrukturieren werde :-)

Trotzdem vielen Dank für die Hilfe!

Zeus Mitglied 13:21:31 04.02.2010 Titel:

Du willst die meistens Methode von LWJGLApplication eher protected haben, oder?

xindon Mitglied 13:35:45 04.02.2010 Titel:

Zeus schrieb:

Du willst die meistens Methode von LWJGLApplication eher protected haben, oder?

Als Beispiel betrachte ich die oben erwähnte libraryDestroy().

Die Methode ist als protected abstract deklariert in der abstrakten Application Klasse. LWJGLApplication erweitert die Klasse und implementiert die Methode libraryDestroy() mit dem üblichen Aufräum-Code von LWJGL.

Die abstrakte Basisklasse Application besitzt nun die Methode start(), die die Initialisierungsmethoden aufruft, die Hauptschleife startet und am Ende eben libraryDestroy() aufruft.

Das Problem ist jetzt aber: Die vom Nutzer implementierte Subklasse von LWJGLApplication hat auch Zugriff auf libraryDestroy() und kann somit das ganze Programm abschießen.

Aber wie gesagt, dieses Design habe ich schon wieder verworfen und es stattdessen über ein paar Interfaces und ohne Vererbung realisiert.

DEvent Mitglied 15:00:42 04.02.2010 Titel:

xindon schrieb:

Das Problem ist jetzt aber: Die vom Nutzer implementierte Subklasse von LWJGLApplication hat auch Zugriff auf libraryDestroy() und kann somit das ganze Programm abschießen.

Und wo soll hier das Problem sein? Wenn ich von LWJGLApplication erbe, dann ist meine Klasse auch eine LWJGLApplication. Das mache ich, wenn ich LWJGLApplication erweitern will um z.B. mit einer anderen Library umzugehen. Dann muss ich sogar libraryDestroy() überschreiben, wo soll ich den sonst meine Libs wieder aufräumen.

Der OOP-Weg ist hier die Klasse LWJGLApplication so zu implementieren, dass man sie als Komposition verwenden kann und man sie nicht zu erweitern braucht. Also statt

Java Code:
class MyApp extends LWJGLApplication { }

Java Code:
class MyApp extends LWJGLApplication { }

Java Code:
class MyApp extends LWJGLApplication { }

besser

Java Code:
class MyApp { private LWJGLApplication app; }

Java Code:
class MyApp { private LWJGLApplication app; }

Java Code:
class MyApp { private LWJGLApplication app; }

Das ist das gleiche Problem den man in vielen Java Beispielprogrammen sieht. Anstatt von JFrame abzuleiten, sollte man lieber Komposition verwenden. Schlecht:

Java Code:
class MyFrame extends JFrame { }

Java Code:
class MyFrame extends JFrame { }

Java Code:
class MyFrame extends JFrame { }

Besser:

Java Code:
class MyFrame { private JFrame frame; }

Java Code:
class MyFrame { private JFrame frame; }

Java Code:
class MyFrame { private JFrame frame; }

Komposition immer der Verwebung vorziehen und dann stellt sich dein Problem erst gar nicht.

Unregistrierter

Noch mal eine Frage zu Komposition.

Welches Komposition meinst du? Das Design-Pattern oder die "Verbindung" in UML?

Meinst du das zweite?

Dasd Mitglied 09:13:12 08.02.2010 Titel:

Letzteres. Geht auch aus den vorherigen Posts hervor.