Problem mit: Vererbung , ADT und einer Funktion

[pyro2k8]

Hallo !

Ich habe ein Problem mit Vererbung im Zusammenhang mit ADTs... (Arraylist).
Die Grundstruktur:

public abstract class Gebjekte { ... }

public class Kreis extends Gebjekte {
public int getMittelpunkt() { ... }

...
}

So, jetzt möchte ich eine Arraylist benutzen, um verschiedene Objekte zu speichern...also:

ArrayList<Gebjekte> tmp = new ArrayList<Gebjekte>();

Da sollen also u.A. Kreis Objekte rein (natürlich habe ich auch noch andere Klassen, die von Gebjekte erben). Jetzt möchte ich später die Funktion getMittelpunkt() aufrufen, z.B.:

System.out.println(tmp.get(0).getMittelpunkt() );

Es wird die Funktion getMittelpunkt nicht gefunden, weil sie in der Klasse Gebjekte nicht vorhanden ist. Ist ja irgendwo auch logisch - aber wie löst man sowas ? Das ist ja eigentlich eine Grundidee der Vererbung, dass ich eine Funktion erst in einer erbenden Klasse habe und diese aufrufen möchte.

Vielen Dank und Grüße,
Tim

 

[Antoras]

public abstract class GeoObjekt {
  public abstract int getMittelpunkt();
}
public class Kreis extends GeoOjekt {
  @Override
  public int getMittelpunkt() {}
}

Edit: Vererbung sollte sparsam benutzt werden. Das hilft dir auch weiter:

public interface GeoObjekt {
  int getMittelpunkt();
}
public class Kreis implements GeoOjekt {
  @Override
  public int getMittelpunkt() {}
}

 

[pyro2k8]

Ja genau die Idee hatte ich auch, aber das Problem ist, dass ich noch eine Klasse Polynom habe (Rechteck bzw. Dreieck), die auch von GeoObjekt erbt.
Ist alles ziemlich sinnfrei Aber ist halt ne Aufgabe die mir so gestellt wurde :/

Wenn ich jetzt ein Interface implementiere und diese Funktion getMittelpunkt() vorgebe, dann wird Sie mitvererbt - aber ich muss sie dann auch in der Klasse Polynom ausführen. Dort soll es die Funktion getMittelpunkt() aber nicht geben.

Weitere Ideen ?

Grüße & erstmal gute Nacht

 

[Wortraum]

Du kannst überprüfen, um was für ein Objekt es sich genau handelt. (Es empfiehlt sich übrigens, sich bei der Schreibung der Klassenamen an Java-Konventionen zu halten und auch nur die Einzahl zu verwenden.)

ArrayList<GeoObjekt> tmp = new ArrayList<GeoObjekt>();
…
for (GeoObjekt o : tmp) {
    if (o instanceof Kreis) {
        Kreis k = (Kreis) o; /* Typumwandlung von GeoObjekt zu Kreis */
        System.out.println(k.getMittelpunkt());
    }
}

Natürlich mußt Du das nicht in einer Schleife machen:

GeoObjekt o = tmp.get(0);
if (o instanceof Kreis) {
    System.out.println(((Kreis) o).getMittelpunkt());
} else {
    System.out.println("Das Geo-Objekt ist kein Kreis.");
}

Es ist auch erlaubt, getMittelpunkt() zu erben, obwohl Polynom keinen Mittelpunkt zurückgeben soll. In der Schnittstelle könnte beispielsweise als Javadoc-Kommentar stehen, daß getMittelpunkt() null zurückgibt, wenn ein Mittelpunkt nicht berechnet werden kann. In Polynom stünde dann einfach:

public Integer getMittelpunkt() {
    return null;
}

Das könnte ebenso auch die Standardimplementation in der Oberklasse sein, so daß jedes GeoObjekt null zurückgibt, das die Methode nicht überschreibt.

Man muß sich natürlich immer fragen, wie sinnvoll das ist, wie aufwendig andere Lösungen sind, ob es ins Konzept paßt, welche Schwierigkeiten entstehen können und so weiter. Hier bekommt man beispielsweise nicht einfach nur int zurück, sondern ein Integer-Objekt, und dann muß man bei jedem Aufruf auf null prüfen. Ich möchte Dir damit auch nur zeigen, daß man eine Methode in einer Schnittstelle oder in einer Oberklasse aufnehmen kann, auch wenn sie bei einer der Unterklassen nichts macht oder nicht so ganz paßt. Die Frage lautet halt immer: Ist es sinnvoll?

 

[Antoras]

Man könnte das auch mit Generics und Polymorphie lösen:

import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;


public class GeoForm {
	
	public static final Sphere GEO_SPHERE = new Sphere();
	public static final Rectangle GEO_RECTANGLE = new Rectangle();
	
	private Map<String, GenericGeoObject<? extends GeoObject>> o = null;

	public static void main(String[] args) {
		new GeoForm();
	}
	
	public GeoForm() {
		o = new HashMap<String, GenericGeoObject<? extends GeoObject>>();
		o.put(Sphere.class.getName(), new SphereImplementation());
		o.put(Rectangle.class.getName(), new RectangleImplementation());
		
		Sphere s = new Sphere(7);
		Rectangle r = new Rectangle();
		
		addType(s);
		addType(r);
		showType(s);
		showType(r);
		System.out.println("Center: " + getCenter());
		System.out.println("Number of lines: " + getNumberOfLines());
	}
	
	@SuppressWarnings("unchecked")
	public <T extends GeoObject> void showType(T geo) {
		getGenericGeoObject(geo).print(geo);
	}
	
	@SuppressWarnings("unchecked")
	public <T extends GeoObject> void addType(T geo) {
		getGenericGeoObject(geo).add(geo);
	}
	
	public int getCenter() {
		return ((SphereGeoObject) getGenericGeoObject(GEO_SPHERE)).getCenter();
	}
	
	public int getNumberOfLines() {
		return ((RectangleGeoObject) getGenericGeoObject(GEO_RECTANGLE)).getNumberOfLines();
	}
	
	@SuppressWarnings("unchecked")
	private <T extends GeoObject> GenericGeoObject getGenericGeoObject(T geo) {
		for (Map.Entry<String, GenericGeoObject<? extends GeoObject>> o : this.o.entrySet()) {
			if (o.getKey().equals(geo.getClass().getName())) {
				return o.getValue();
			}
		}
		return null;
	}
}

interface GeoObject {}

class Sphere implements GeoObject {
	private int m;
	public Sphere(int m) { this.m = m; }
	public Sphere() {}
	public int getCenter() { return m; }
}

class Rectangle implements GeoObject {
	private int a, b, c, d;
}

interface GenericGeoObject<T> {
	void print(T geo);
	void add(T geo);
}

interface SphereGeoObject extends GenericGeoObject<Sphere> {
	int getCenter();
}

interface RectangleGeoObject extends GenericGeoObject<Rectangle> {
	int getNumberOfLines();
}

class SphereImplementation implements SphereGeoObject {
	
	private List<Sphere> l = new ArrayList<Sphere>();

	@Override
	public int getCenter() {
		return l.get(0).getCenter();
	}

	@Override
	public void print(Sphere geo) {
		System.out.println("Sphere");
	}

	@Override
	public void add(Sphere geo) {
		l.add(geo);
	}
}

class RectangleImplementation implements RectangleGeoObject {
	
	List<Rectangle> l = new ArrayList<Rectangle>();

	@Override
	public int getNumberOfLines() {
		return 4;
	}

	@Override
	public void print(Rectangle geo) {
		System.out.println("Rectangle");
	}

	@Override
	public void add(Rectangle geo) {
		l.add(geo);
	}
}

Ok, den Code dürftest du jetzt nicht komplett verstanden haben. Hab hier auch mit Kanonen auf Spatzen geschossen. Und bin mir jetzt nicht mal mehr sicher ob der Code überhaupt das macht was du brauchst. Nimm lieber den von meinem Vorposter.
Aber du siehst schon, das wird alles schnell kompliziert, vor allem wenn sich die einzelnen Objekte wie jetzt bei dir nicht stark genug voneinander unterscheiden.

Guter Rat: Such nicht nach Gleichnissen wenn es keine gibt. Benutz lieber nur eine Oberklasse in der nur das drinsteht was auch gleich ist. Den Rest musst wohl selbst implementieren.

Speicher den Code von mir irgendwo und erinnere dich in nem Jahr noch mal daran, dann wirst von dem nämlich begeistert sein...

 

[Wortraum]

Ich bin begeistert ob all der genutzten Möglichkeiten, nur der Nutzen verschließt sich mir noch. Vielleicht kannst Du dazu ein paar Zeilen schreiben.
(Ich meine das nicht ironisch.)

 

[Antoras]

Die Frage nach dem Nutzen hab ich mir auch gestellt nachdem ich mit dem Code fertig war. Ursprünglich hab ich den Aufbau des Codes dem DAO-Pattern nachempfunden. Übrig geblieben ist die Polymorphie und die Möglichkeit Teile der Logik einfach auszutauschen bzw. zu erweitern.

Der Code lohnt sich allerdings erst dann, wenn er als Art API genutzt wird. Wenn mehrere Programmieren an einem Projekt beteiligt sind ermöglicht er, dass diejenigen, die die API nur nutzen nicht wissen müssen wie die Logik auf den Aufruf reagiert. In diesem Fall können beliebige Objekte an die Methode

showType()

übergeben werden. Durch Änderung des Codes wäre es außerdem möglich beliebige Kreisobjekte an die Methode

getCenter()

zu übergeben - die Logik würde dafür Sorgen, dass der richtige Mittelpunkt ermittelt wird. Die zu übergebenen Objekte wären hier Sphere und Rectangle, die nur die Attribute, aber keine Logik beinhalten. Auch müsste man sich keine Gedanken um die Speicherung der Objekte machen - ein Gedanke,der auch dem DAO-Pattern entsprungen ist. Die Ermittlung des Mittelpunktes ist allerdings so einfach, dass es eigentlich keinen Sinn macht dessen Implementierung in die Implementierungsobjekte zu stecken.

Der Haken an der ganzen Sache ist der, dass man erstens nur Objekte übergeben kann, die der Logik bereits bekannt sind und zweitens, dass man alle Methoden die nicht in dem

GenericGeoObject<T>

vorhanden sind noch mal explizit in dem Controller deklarieren muss.
Ich bin allerdings gerade dabei ein Art Plugin-System zu entwickeln, das dem Nutzer ermöglichen soll, dass er neue Objekte ohne Änderung des Quelltextes der API benutzen kann. Weiter bin ich gerade am rumüberlegen wie man letzteren genannten Nachteil umgehen kann. Ich hab mir gedacht, dass es eine Methode

getSpecificObject(...)

geben könnte, die einem anhand von einem übergebenen String zur Laufzeit den Rückgabewert ermittelt. Das funktioniert aber noch nicht so wie ich mir das vorgestellt hab, auch weil ich momentan keine Zeit hab da effektiv weiterzuarbeiten.

In obigen Fall wäre das ganze aber viel zu overpowered. Aber man kann es sich ja für später aufheben und es wieder rausgraben wenn es sinnvoll nutzbar scheint...

 

[faetzminator]

Ja genau die Idee hatte ich auch, aber das Problem ist, dass ich noch eine Klasse Polynom habe (Rechteck bzw. Dreieck), die auch von GeoObjekt erbt.

Zumindest beliebige Drei- und Vierecke und 360/n° n-Ecke haben doch auch einen "definierten" Mittelpunkt? Von einem Rechteck (Pos [c]{x, y}[/c] links oben) wär das [c]{x + w/2, y + h/2}[/c].

 

[Wortraum]

@Antoras:
Ich verstehe. Danke Dir für Deine Antwort!

@faetzminator:
Man müßte die mathematischen Kenntnisse haben, um einen Mittelpunkt zu errechnen.

Es geht wohl auch nicht darum, ob das Ding nun einen Mittelpunkt hat oder nicht, sondern wie man eine Methode objektorientiert verwurstet, wenn es erbende Objekte gibt, die mit dieser Methode nichts anfangen können. Stattdessen könnte man auch Fahrzeug, Auto und Eisenbahn und eine Methode getReifenLuftdruck() nehmen.

 

[Schumi]

Die Frage ist doch, warum willst Du in einem Kontext, in dem Du nur die Oberklasse hast (also bei der Verwendung des Arrays) jetzt eine Methode verwenden, welche nur in bestimmten Unterklassen definiert ist. (Was soll denn in diesem Arbeitsschritt mit den anderen Klassen passieren?)
Das ist imo ein Problem, welches man schon Designseitit zu verhindern versuchen sollte.

 

[Wortraum]

Natürlich sollte man versuchen, so etwas nicht in Übermaß zu produzieren. Oft sind die Dinge aber nicht so klar trennbar, man merkt erst später, daß man sich verplant hat, oder man arbeitet mit fremden Klassen. Das Ergebnis kann ja trotzdem übersichtlicher, einfacher und verständlicher sein als eine komplexe, überzogene, aber theoretisch elegante Lösung.

Aber Du hast recht, daß es ebenso ein Indiz für ein Entwurfsfehler sein kann. Ich selbst tue mich mit solchen Entscheidungen schwer; es ist einfach eine Frage der Erfahrung und des Wissens. Ich sage auch nur, daß es diese Möglichkeit gibt und daß man sie in der Praxis auch verwendet (und man findet so etwas sogar im JDK selbst).

Wenn jemand eine gute Idee hat oder einen besseren Vorschlag machen kann, interessiert mich das auch; man möchte ja hinzulernen. „Das kann man besser machen“ hilft leider nicht viel.