Saubere Verwendung von Generic Types

[Kasperdelasopa]

Hallo,

ich möchte folgende Struktur umsetzen:



CardReader und Formatter sind Interfaces.

AbstractReaderX und AbstractFormatterX.X sind abtrakte Klassen.

ConcreteReaderX und ConcreteFormatterX.X sind Klassen die die jeweiligen abstrakten Klassen implementieren sollen.

Natürlich möchte ich hier das ein ConcreteReader1 nur Objekte vom Typ ConcreteFormatter1.1.X annimmt (Analog auch der ConcreteReader2)

Ich würde bei dem Klassendesign diese Einschränken über Generic Types abbilden.
D.h. die Klasse ConcreteReader würde ich so definieren

public class ConcreteReader1<T extends AbstractFormatter1.1> extends AbstractReader<T> {

	@Override
	public void setFormatter(T formatter) {
		// TODO Auto-generated method stub		
	}
}

Mich würde interessieren ob ein solchen Vorgehen als "sauberes Vorgehen" zu definieren wäre. Oder ob es komplett die Idee der Objektorientierung sprengt.

 

[Tobse]

Ich denke nicht, dass das funktioniert. Wenn das Interface CardReader mit Formatter definiert ist, müssen alle Erbenden Klassen das auch so implementieren; ergo muss jeder CardReader mit jedem Formatter zurechtkommen.

 

[Kasperdelasopa]

Oh sorry, das Schaubild widerspricht dem was ich programmiert habe. Tatsächlich wurde hier der generische Typ T verwendet.

public interface CardReader<T extends Formatter> {

	@Override
	public void setFormatter(T formatter) {
		// TODO Auto-generated method stub		
	}
}

 

[Tobse]

Achso, okey.

Als was "sauber" ist und was nicht, ist erstmal nicht so genau zu definieren. Ich persönlich finde es eine durchaus brauchbare Lösung für das Problem und ich sehe spontan auch kein Problem damit. Solange sich an der Grundlegenden Architektur nichts ändert sollte das auch ausreichen.

 

[Kasperdelasopa]

Das es so funktioniert weiß ich. Nur würde mich persönlich interessieren ob man diese Anforderung nicht geschickter lösen könnte

Gruß

 

[Thallius]

Ich verstehe dem Sionn des Ganzen noch nicht. Vor allem verstehe ich die Verbindung zwischen dem Abstract-Fomatter und dem Abstract-Reader so gar nicht? Wie soll das gehen? Das geht ja nur, wenn AbstractFormatter und ABstractReader immer genau das gleiche machen und dann sind sie ja nicht mehr abstract?
Wozu brauchst du die Abstracten Klassen überhaupt? Also ich meine das Interface erwartet ja schließlich irgendein definiertes Ergebnis. Dieses Ergebnis müssen die Klassen, welche das Interface implementieren erzeugen. Dazu brauche ich aber keine Anstracte Klassen oder?

Gruß

Claus

 

[Kasperdelasopa]

Prinzipiell sollen alle Reader die gleichen Funktionen bereit stellen. Deswegen das zentrale Interface.

Die abstrakten Klassen sollen eine Stufe einfügen, um konkrete Reader eines Herstellers zusammen zu fassen.

Jeder Reader kann verschiedene Medien lesen, die aber abhängig von Reader unterschiedlich formatiert werden müssen.

 

[Tobse]

Jeder Reader kann verschiedene Medien lesen, die aber abhängig von Reader unterschiedlich formatiert werden müssen.

Wenn ein konkreter Reader anforderungen an das Format stellt, sollte er den Formatter auch selbst bestimmen. Wenn beide Hersteller unterschiedliche Daten speichern, macht es keinen Sinn, sie so über einen Kamm zu scheren.

ODER aber jeder Reader bestimmt einen Converter selbst, der die Hersteller-Spezifischen Datenstrukturen in eine allgemeingültige Datenstruktur überführt, die wiederrum von einer konkreten Implementierung von CardReader weiterverarbeitet wird.