vererbung einer "selbst-instanzierungs-klasse"

[MamboKurt]

hmm ich hab da eher eine kleine - wahrscheinlich dumme - frage:
also mein ziel ist es mehere klassen zu schreiben, die sich slebst verwalten. dazu will ich , dass sich objekte nicht von außen einsehen oder direkt verändern lassen. dies soll alles über statische methoden laufen, in denen ich genau festlegen, was zu tun ist. ich wollte in guter objekt-orientierten arbeitsweise dies über vererbung machen und zwar ähnlich wie folgt:

// Oberklasse --------------------
import java.util.vecotr;

class Oberklasse
{
   private Oberklasse(){}

   public static void create()
   {
      objectvector.add(new Oberklasse());
   }

   public static void doSomeFancyStuffWithTheObjectsInTheVector()
   {
      // hier wir was mit den Objekten gemacht, die im Vector stehen
   }

   protected static Vector objectvector = new Vector();
}

// Unterklasse I ----------------

class UnterklasseI extends Oberklasse
{
   private UnterklasseI(){}

   public static void doSomeCrazyStuffWithTheObjectsInTheVector();
   {
      // hier wir was mit den Objekten gemacht, die im Vector stehen
   }
}

// Unterklasse II ---------------

class UnterklasseII extends Oberklasse
{
   private UnterklasseII(){}

   public static void doSomeCoolStuffWithTheObjectsInTheVector();
   {
      // hier wir was mit den Objekten gemacht, die im Vector stehen
   }
}

da beide Unterklassen von Oberklasse erben bekommen ja beide die methode create(). leider wird hier in den Unterklassen kein Unterklassen-onjekt erzeugt, sondern ein Oberklassen-objekt, oder sehe ich das falsch? wie bekomme ich das hin, dass in der geerbten methode ein Unterklassen-onjekt erzeugt wird?
prinzipiell hätte ich ja eine static abtract-methode geschrieben, aber das geht ja nicht.
Wenn jemand einen vorschlag hat, dann bitte her damit. ich wäre euch sehr verbunden.

.MamboKurt

 

[AlArenal]

1. die Nutzung von statischen Methoden ist auf ein Minimum zu reduzieren
2. die Manipulation von außen kannst du über die Einstellungen zur Sichtbarkeit von Feldern und Methoden steuern

 

[MamboKurt]

hmm ja danke für deine antwort, aber das löst mein problem nicht

 

[AlArenal]

Warum überschreibst du #create nicht einfach? Und wazu soll das ganze dienen?

 

[alehandro]

na die create() überschreiben halt

edit: upsss

 

[MamboKurt]

eigenltich wollte ich das ganze via vererbung machen, da ich evtl viele klassen mit diesen eigenlschaften schreiben will und mir den aufwand sparen wollte in jeder klasse die selbe createmethode schreiben zu müssen.
das ganze dient dazu, dass die klasse alle ihre instanzen selbst verwalten soll, da die instanzen alle gleichwertig und automatisiert behandelt werden. deshalb wollte ich alles in die klasse statisch einbinden und die instanzen als protected deklarieren, damit kein anderer direkten zugriff drauf hat.

 

[AlArenal]

Ich nehme an, da liegt ein grundsätzlicher Designfehler zugrunde. Stopf deine Klassen in ein eigenes Package, mach die abgeleiteten Klassen nur im Package sichtbar und schon kommt "kein anderer" dran.

Ich rate dir, dir mal gute Literatur zu Klassendesign und Design Pattern reinzuziehen.

 

[MamboKurt]

ja ok danke. ich komme von c++ und bin das mit den packages noch nicht so gewöhnt, auch wenn in c++ ähnliche konzepte gibt.
hast du tips, welche literatur da zu empfehlen ist?

 

[Murray]

Wenn Du irgendwo zum Erzeugen von UnterklasseI etwas schreiben willst wie

UnterklasseI.create();

,dann musst Du in den Unterklassen eine entsprechende create-Methode implementieren (von Überschreiben würde ich hier nicht sprechen, da statische Methoden nicht wirklich überschrieben werden).

Wenn Du aber auch mit dieser Syntax

Oberklasse.create( Unterklasse.class);

leben kannst, dann sollte das so gehen:

class Oberklasse
{
   private Oberklasse(){}

   public static void create( class concreteClass) throws InstantiationException, IllegalAccessException
   {
      objectvector.add( concreteClass.newInstance());
   }

   public static void doSomeFancyStuffWithTheObjectsInTheVector()
   {
      // hier wir was mit den Objekten gemacht, die im Vector stehen
   }

   protected static Vector objectvector = new Vector();
}

 

[AlArenal]

ja ok danke. ich komme von c++ und bin das mit den packages noch nicht so gewöhnt, auch wenn in c++ ähnliche konzepte gibt.
hast du tips, welche literatur da zu empfehlen ist?

- Thinking in Java, Bruce Eckel - vorletzte Verison gibts auch frei als PDF
- Professional Java Programming, Brett Spell, Wrox - vergriffen
oder
- Pro Java Programming, Brett Spell, Apress
- Java Design Patterns Workbook, Steven John Metsker, Addison Wesley Pro

 

[Reinski]

1. die Nutzung von statischen Methoden ist auf ein Minimum zu reduzieren

Darf ich mal fragen, wieso das so ist?
Gruß!

reinski

 

[Wildcard]

Weil es keinen Sinn macht Java zu programmieren wenn man es nicht objektorientiert tut.

 

[Reinski]

ja aber statische methoden sind doch Bestandteil des OO Konzeptes, oder?
Bzw. es macht doch Sinn, Methoden, die nicht Instanz-abhängig sind, auch als solche zu deklarieren?
Vielleicht kannst Du mir nen Link posten, wo diese Thematik (kritisch) besprochen wird, damit du das hier nicht alles schreiben musst... ;-)
Danke schonmal!

reinski

 

[Wildcard]

static ist sozusagen das Gegenteil von OOP. In Java wird static eigentlich nur für Utility Klassen u.ä. verwendet, die nur ein paar Berechnung ausführen..
Am besten lernt man OOP in dem man komplett auf den Einsatz von static verzichtet. Irgendwann sieht man dann von alleine wo es sinnvoll ist trotzdem static zu verwenden.
Link kann ich dir keinen anbieten

 

[bygones]

natürlich macht es sinn bzw ist es vertretbar static zu verwenden..

aber nur in bestimmten Fällen

Sobald es um Konstante bzw um Variablen geht, die für eine Klasse gelten und nicht für eine Instanz.
Für Methoden einer Util Klasse, die man nicht instanzieren kann / möchte / muss (z.b. Math)

Alles andere ist static unsinn.

OOP lebt von dem Verhalten und den Eigenschaften von Objekten. Man baut nicht 100 gleiche Autos und fährt die identisch, sondern jedes Auto ist anders, hat einen anderen Fahrer, ein anderes Nummernschild... wo zum Teufel soll hier static sinnvoll sein ?

nein - static ist und bleibt für ausnahmen - punkt 🙂

 

[AlArenal]

http://www.artima.com/designtechniques/static.html

 

[Murray]

Statische Methoden haben m.E. mindestens zwei schwerwiegende Nachteile: sie können nicht überschrieben werden, und es kann in einer Anwendung niemals zwei verschiedene Implementierungen geben. Beides kann sich im Rahmen einer späteren Weiterentwicklung als hinderlich erweisen und erhebliche Änderungen erfordern.

Vorteil von statics: man spart sich die Erzeugung von Objekten und das Abräumen derselben durch den Garbage-Collector, was ja zur Laufzeit einen gewissen Overhead verursacht.

Und in manchen Situationen will man ja auch erzwingen, dass es ein Objekt im System nur einmal gibt (Stichwort Singleton), da ist static eben durchaus angezeigt.