Generisch implementieren

[Tucan]

Wie implementiert man generisch?

 

[Flown]

Eine simple Frage, aber eine komplexe Antwort.

Wenn eine Implementierung mit mehreren Datentypen was zu tun haben soll, dann verwendet man Generics.

Ansonsten Interface.

 

[Tucan]

Ja, aber wie macht man das??!

 

[Tucan]

Im konstruktor mit <Object> oder wie??!

 

[nvidia]

Ja, aber wie macht man das??!

Man liest die Grundlagen z.B. in einem Buch wie dem hier: Java Generics and Collections: Amazon.de: Maurice Naftalin, Philip Wadler: Fremdsprachige Bücher

 

[Flown]

Ja Literatur zu Java Generics und vor allem Softwarearchitekturbücher(wenn es ein einfaches Thema wäre, dann wäre es keine eigene Disziplin in der Informatik) könnten dir helfen. Deine Frage ist selbst so generisch das man dir darauf nur generisch antworten kann.

Schau dir mal die Implementierung von Listen in der Standardlibrary von Java an.

 

[kaoZ]

Ein einfacher Hinweis:

public class Entity<T>{
....
}

T steht hier nicht für einen Bestimmten Typ, sondern dient einzig und allein als Platzhalter für den dort später verwendeten Konkreten und oder Abstrakten Typ.

Das hilft dir vielleicht schonmal im Ansatz weiter

 

[Thallius]

Ein einfacher Hinweis:

public class Entity<T>{
....
}

T steht hier nicht für einen Bestimmten Typ, sondern dient einzig und allein als Platzhalter für den dort später verwendeten Konkreten und oder Abstrakten Typ.

Das hilft dir vielleicht schonmal im Ansatz weiter

Was ja alleine schon totaler Schwachsinn ist, denn sonst steht ja auch kein Typ hinter dem Klassenamen. Wozu soll das also eigentlich gut sein?

Gruß

Claus

 

[kaoZ]

Was ja alleine schon totaler Schwachsinn ist, denn sonst steht ja auch kein Typ hinter dem Klassenamen. Wozu soll das also eigentlich gut sein?

Bitte was ? Ich kann gerade glaube ich daraus nicht schließen worauf du mit dieser Aussage hinaus möchtest.

denn sonst steht ja auch kein Typ hinter dem Klassenamen.

Sonst sind "normale" Klassen auch nicht Generisch......

Aber bitte kläre mich doch erstmal auf worauf du mit deiner Aussagen hinaus willst.

 

[Thallius]

Bitte was ? Ich kann gerade glaube ich daraus nicht schließen worauf du mit dieser Aussage hinaus möchtest.

Eine "normale" Klassendefinition sieht so aus:

public class MeineKlasse
{
}

Die hat aber erstmal überhaupt keinen Typ. Es ist halt eine Klasse. Was hat die mit generic oder nicht zu tun?

Gruß

Claus

 

[Joose]

Die hat aber erstmal überhaupt keinen Typ. Es ist halt eine Klasse. Was hat die mit generic oder nicht zu tun?

kaoZ wollt als Ansatz eine generische Klasse zeigen (und davon auch nur die Klassendefinition).
Da es sich bei diesem Thema um eine Frage nach Generics handelt passt es schon.

 

[kaoZ]

Die hat aber erstmal überhaupt keinen Typ. Es ist halt eine Klasse. Was hat die mit generic oder nicht zu tun?

Öhm, ich hab kein Plan was genau gerade dein Problem ist,


Natürlich haben nicht Generische Klassen auch keine Angabe eines Generischen "Platzhalters" / Typs.....

sie sind eben nicht Generisch ........

Es ging lediglich darum dem TO zu vermitteln das er sich von der Typangabe in der Klassendefinition nicht verwirren lassen soll wenn er sich dies in der Collecitons-API anschaut ( wie dies oben als Tip erwähnt wurde), da dies einfache Platzhalter für den späteren Typ sind.

Bei der unheimlich konkreten Fragestellung des TO 's dachte ich es eben es liegen keine Kenntnisse dahingehen vor. demnach diente das ledigleich als Hilfestellung insofern er sich in der API austobt und sich den Aufbau Generischer Klassen zuführt.

Danke Joose, anscheinend konnte man ja dem doch entnehmen worauf ich hinaus wollte.

Wenn man eben nicht die Weisheit mit Löffeln gefressen hat, und eben keine Vorkenntnisse in diesem Bereich hat, kann einen eine Klassendefinition mit solch meinstens sehr abstrakten bezeichnungen wie <K,V> oder auch <E> oder <T> halt anfänglich verwirren wenn man nicht weiß das diese eben nur "Platzhalter" darstellen...

um mehr ging es bei diesem Hinweis garnicht.......konnte ja keiner ahnen das man dann hier neuerdings gleich mit solchen statements wie "totaler schwachsinn" angefahren, wird, was es bei weitem nicht ist wie ich finde.


Ausserdem kann ich nichts dafür wenn du ein Generics-hater bist :bae:

Offtopic

Das fängt ja schon mit den Generics an. Java war ja stolz darauf eine streng statisch typisierte Sprache zu sein. Blöd wenn man dann irgendwann feststellt, dass man damit manche Sachen einfach nicht realisiern kann und dann bastelt man halt schnell noch die Generics dazu.

 

[Thallius]

Hey KaoZ,

ganz ruhig. Das totaler Schwachsinn war nicht auf Dich gemünzt, sondern meine persönliche Meinung zu der Art wie generics in Java implementiert sind. Das finde ich totalen Schwachsinn.

Eine Klassendefinition hat für mich nichts aber auch gar nichts mit einem Typen zu tun. Eine Klasse hat niemals einen Typ. Eine Klasse ist eine Klasse. Nicht mehr und nicht weniger. Ich finde eine generische Klasse ist wie ein rundes Rechteck. Das passt einfach nicht ... Aber das ist meine persönliche Meinung und millionen andere finden GEnerics in Java bestimmt ganz toll.

Gruß

Claus

 

[Joose]

Eine Klassendefinition hat für mich nichts aber auch gar nichts mit einem Typen zu tun. Eine Klasse hat niemals einen Typ. Eine Klasse ist eine Klasse.

Was ist denn für dich ein Type? Eine Klasse hat keinen Typ meinst du, hat das Objekt einer Klasse einen Typ?

Ich frage nur nach, weil ich probieren will deine Sichtweise nachzuvollziehen

 

[kaoZ]

Das totaler Schwachsinn war nicht auf Dich gemünzt, sondern meine persönliche Meinung zu der Art wie generics in Java implementiert sind. Das finde ich totalen Schwachsinn.

Mein Fehler, habe ich falsch verstanden.

Eine Klassendefinition hat für mich nichts aber auch gar nichts mit einem Typen zu tun. Eine Klasse hat niemals einen Typ. Eine Klasse ist eine Klasse. Nicht mehr und nicht weniger. Ich finde eine generische Klasse ist wie ein rundes Rechteck. Das passt einfach nicht ... Aber das ist meine persönliche Meinung und millionen andere finden GEnerics in Java bestimmt ganz toll.

Stimme ich so zu, wenn man Allerdings mit Generics arbeitet, nun stellen wir mal dahin ob es nun gut oder schlecht ist, bin ich dazu gezwungen bereits in der Klassendefinition, insofern ich später die Objekte dieser Klasse generisch verwenden möchte, anhand eines Platzhalters <PlaceHolder> festzulegen das es sich eben um eine Generische Klasse handelt.

Ob das jetzt gut oder schlecht ist , stelle ich nicht in Frage, da aber jemand wie z.B ich diese Thematiken ( und das liegt einfach daran das z.B jemand wie ich der diese Sprache erst erlernt hat, als Generics bereits Bestandteil dieser waren ) nicht anders kennt, isses für mich und eben auch für den TO vielleicht garnicht so schlimm das man hier eben versucht aus einem Rechteck einen Kreis zu formen, das wie eben erwähnt man es ggf. vorher garnicht anders kannte

Aber das steht nunmal auf einem anderen Blatt,

Es ist also egal ob ich eine Methode habe die Generische Paramter verwendet, oder mir ein Objekt eines Generischen Typs zurückgibt, der Typ muss irgendwo festgelegt sein , egal ob in der Klassen oder Methodendefinition.

Aber es ging ja hier auch nicht darum ob es Sinn macht überall mit generischen Typen zu arbeiten

 

[Thallius]

Was ist denn für dich ein Type? Eine Klasse hat keinen Typ meinst du, hat das Objekt einer Klasse einen Typ?

Ich frage nur nach, weil ich probieren will deine Sichtweise nachzuvollziehen

Es leuchtet mir einfach nicht ein, warum ich die Quelle, also die Klasse als generisch typisieren muss, damit das Ziel (Die Methode, die Variable die das Object hält oder was auch immer) damit umgehen kann.

Warum kann nicht einfach das Ziel beliebige Typen aufnehmen, aber das wären dann ja wieder untypisierte Variablen und das gibt es ja nicht in Java. Deshalb macht man es lieber kompliziert, damit man keine Fehler machen kann, die man sowiso nicht machen würde.

Gruß

Claus

 

[kaoZ]

Es leuchtet mir einfach nicht ein, warum ich die Quelle, also die Klasse als generisch typisieren muss, damit das Ziel (Die Methode, die Variable die das Object hält oder was auch immer) damit umgehen kann.

Zum einen muss ja der ggf. Implementierten Methode der Type den sie zu erwarten hat irgendwo bekannt gemacht werden, um eben Flexibilität zu gewährleisten, darüber hinaus sparst du dir so unheimlich viel (Redundanten) Code, da du nicht für jeden Typen die ggf. gleiche Funktionalität neu Implementieren musst.

Zum anderen sei angenommen wir haben eine Speicherstruktur wie eine List, und diese ist nicht Generisch (RawType), so kannst du nicht garantieren das ein ggf. dort belegtes Feld den von dir erwarteten Typ enthält, wenn du nun z.B über einen Getter einen bestimmten Indizes abrufst und der Rückgabewert eben nicht wie erwartet z.b vom Typ String ist, sonder sagen wir Integer, läufst du Gefahr das die Anwendung sich zur laufzeit verabschiedet, oder eine von dir implementierte Methode eine Exception wirft.

Durch das Festlegen des Typs beim Intanziieren List l = new List<String>(); kannst du so gewährleisten das diese liste eben auch nur Objekte des Typs aufnimmt, und das macht wie ich finde schon Sinn.

Sicher macht der Einsatz von Generics nicht überall Sinn, aber er macht doch gewisse dinge teilweise recht angenehm.

Ich hoffe du weißt worauf ich hinaus will, ich wüsste zumindest nicht wie man genau diesen Sachverhalt hätte besser ( nachträglich in einer Typensicheren Hochsprache ) lösen können.

 

[Joose]

.... Festlegen des Typs beim Intanziieren List l = new List<String>(); ....

Eben die Klasse ist für mich der Bauplan eines Objektes, und dazu gehört auch die generische Information. Und diese wird beim Bau des Objektes (über den Konstruktor) benötigt.

... Objekte des Typs ....

Diese Phrase (und die obere) sind eben das was zu beachten wäre.
Ein paar Posts vorher wird davon gesprochen Klasse != Type .... aber hier legt ihr den Typ fest und dieser ist in diesem Fall nichts anderes als die Angabe einer Klasse.

 

[kaoZ]

Es ist jetzt vielleicht nicht das Schönste Beispiel ( alleine Schon weil es eben Statisch ist)

aber ich hoffe man versteht worauf ich hinausmöchte :

public class Foo{

	
	public Foo(){}
	
	public static <T extends Serializable> void store(T t, File f){
		
		FileOutputStream fos;
		ObjectOutputStream out;
		try {
			fos = new FileOutputStream(f);
			out = new ObjectOutputStream(fos);
			out.writeObject(t);
		}
		catch (Exception e) {
			e.printStackTrace();
		}
	}
	
	public static void main(String[] args){
		Foo.store("StringExample", new File("H:/Apps/string.ser"));
		Foo.store(4, new File("H:/Apps/int.ser"));
	}
}

Natürlich könnte man hier auch einfach als Parameter das Interface verwenden, aber es geht ja auch nur ums Prinzip, zudem gibt es eben auch Fälle bei denen die Nutzung von Generics weitaus Sinnvoller ist als in dem kurzen anriss oben, zum Beispiel bei nicht statischen Methoden, bei den sicherzustellen ist das nur bestimmte Objekte eines Typs (<- Phrase) verwendet werden können :lol:

Diese Phrase (und die obere) sind eben das was zu beachten wäre.

Eben, der Typ ist ja im Grunde auch nichts weiter als die Angabe zur welcher Klasse die später verwendeten Objekte gehören.

 

[Thallius]

Gerade bei Listen verstehe ich die strenge Typisierung überhaupt nicht.

Was für einen Quatsch muss man denn programmieren, dass man aus versehen verschiedene Objecte in eine Liste packt? Entweder ich mache das bewußt, dann lebe ich auch mit den Konsequenzen oder ich lasse es. Aber aus versehen? Also das ist mir in über 30 Jahren in C noch nie passsiert.

Und damit man es jetzt in Java doch machen kann, muss man einen risen Aufwand treiben der syntaktisch so häßlich ist, dass es mir immer die Fußnägel aufrollt.

Da wäre ein

ArrayList<id>

doch viel eleganter und damit alles abgedeckt.

Gruß

Claus

 

[kaoZ]

Seien wir ehrlich, lustig wird es erst wenn wir listen haben die listen generischen Typs beinhalten ^^

	 Map<Integer, ArrayList<? extends Serializable>> map = new HashMap<>();

Die Syntax wird selbstverständlich mit zunehmender tiefe immer unlesbarer und komplexer, da muss ich zustimmen, wobei obiges noch im Rahmen des doch recht gut nachvollziehbaren liegen sollte.

 

[Joose]

Gerade bei Listen verstehe ich die strenge Typisierung überhaupt nicht.

Was für einen Quatsch muss man denn programmieren, dass man aus versehen verschiedene Objecte in eine Liste packt? Entweder ich mache das bewußt, dann lebe ich auch mit den Konsequenzen oder ich lasse es. Aber aus versehen? Also das ist mir in über 30 Jahren in C noch nie passsiert. ....

Beispiel: ArrayList<Superklasse> kann Objekte jeder Kindklasse von Superklasse haben.
Und solche werden eben bewusst eingesetzt.

....
Und damit man es jetzt in Java doch machen kann, muss man einen risen Aufwand treiben der syntaktisch so häßlich ist, dass es mir immer die Fußnägel aufrollt.
....

Dem Stimme ich zu wenn es um komplexe generische Verschachtelungen usw. geht.

....
Da wäre ein

ArrayList<id>

doch viel eleganter und damit alles abgedeckt.

Was ist in diesem Fall "id"?

 

[Thallius]

id ist irgendein Object (Kein Primitiv)

Gruß

Claus

 

[JavaMeister]

Gerade bei Listen verstehe ich die strenge Typisierung überhaupt nicht.

Das macht nix, wenn du das nicht verstehst. Ist auch schwer, wenn man gerade erst wenige Monate in Java programmiert und noch kein größeres Projekt implementiert hat.

Die wahre Stärke eines solchen Konstruktes wird erst deutlich, wenn du nicht jede Liste zu seinem eigentlichen Zielobjekt casten musst oder mit instance of prüfen musst, was den drin ist, um damit zu arbeiten.

Auch hilft es Fehler schon zur Compilezeit zu identifizieren und in der IDE entsprechende Empfehlungen zu geben, was eine Methode erwartet und wann.

Zur Laufzeit wird aufgrund des Type Erasure ehh nicht mehr mit den typisierten Werten gearbeitet. Das bedeutet, dass du via einfachen Reflection immer noch dort Objekte reinbekommst, die nicht durch den Typ eingeschränkt sind. Das Ergebnis wird eine ClassCastException sein.

Natürlich haben Generics ihre Grenzen, besonders dann wenn man auf den tatsächlich angegebenen Typ zur Laufzeit angewiesen ist.

Es wäre auch deutlichst angenehmer mit einem solchen alten Hasen der Informatik zu diskutieren, wenn unbekannte Strukturen nicht sofort absoluter bullshit wären. Wäre auch taktisch sinnvoll seine eigene Meinung durch entsprechende Quellen und/oder Beispiele zu belegen. Naher lesen das hier Newbes und denken "Hey Exceptions - BRAUCHE ICH NICHT" oder Generics - Was das für nen S*****.

Auch denn, wenn man ein paar mehr Postings hat, tendieren die Leute die Aussagen von solchen Usern als bare Münze zu nehmen. Und das wäre hier fatal.

Und als Abschluss fällt mir ein netter Stromberg-Zitat ein: Wer nicht mit der Zeit geht, muss mit der Zeit gehen

 

[Thallius]

Lieber JavaMeister (sorry aber alleine der Nick erzeugt bei mir fürchterliche antipathie, denn selbst nach über 30 Jahren C würde ich mich nicht als CMeister titulieren und wahrscheinlich programmiere ich schon doppelt so lang wie du alt bist)

Ich würde ja gerne mit dir diskutieren aber zum diskutieren benötigt es Argumente. Davon lieferst du aber überhaupt keine. Du sagst nur was ich sage ist Mist und ich bin von gestern nur weil ich nicht alles neue gut finde. Das ist für mich aber keine Grundlage zu diskutieren. Akzeptiere deshalb bitte, das ich dich nicht wirklich ernst nehme und in Zukunft einfach ignoriere.

Gruss

Claus

 

[JavaMeister]

Lieber JavaMeister (sorry aber alleine der Nick erzeugt bei mir fürchterliche antipathie, denn selbst nach über 30 Jahren C würde ich mich nicht als CMeister titulieren und wahrscheinlich programmiere ich schon doppelt so lang wie du alt bist)

^^ Das habe ich mit dem Nick nun überhaupt nicht vor gehabt sorry (Für die, die es nicht verstehen, IRONIE!).

Den rest lasse ich mal so stehen ^^. Wer meine Postings nicht liest, brauche ich nicht weiter zu beachten

 

[kaoZ]

Die Sache ist doch die, insofern es nicht vorausgesetzt wird muss ja niemand mit Generics arbeiten.

Ich für meinen Teil halte es in einigen Anwendungsfällen und um Redundanz zu unterbinden vollkommen für legitim die Möglichkeiten die einem hiermit geboten werden zu nutzen.

Um auf die eigentliche Frage des TO's zurück zu kommen:

Die Implementierung von Generics kommt immer auf den Anwendungsfall an zum einem im Bereich der Datenhaltung, zum anderen um eben Redundanz ( also das Wiederholen von bereits existierendem Code , für einen ähnlichen oder sogar den gleichen Anwendungsfall, mit anderen Datentypen zu unterbinden ).

Im Groben hatte Flown schon den mit besten Tip gegeben, schau dir einfach mal die Implementierung des Collection Frameworks an.

Und dann stell dir vor man hätte sich nicht dafür entschieden dies Generisch aufzubauen,

und man müsste somit für jeden Datentyp z.B eine ArrayList komplett selbst implementieren.

 

[ceving]

Was ja alleine schon totaler Schwachsinn ist, denn sonst steht ja auch kein Typ hinter dem Klassenamen. Wozu soll das also eigentlich gut sein?

Damit man Listen unterschiedlicher Typen machen kann, ohne für jede Art einer Liste, die Listenimplementation neu schreiben zu müssen?

List (Java Platform SE 7 )

Eine Liste ist eine generische Datenstruktur. Der Liste ist es egal, was in ihr abgespeichert wird. Das gleiche gilt für das Sortieren. Ein Quicksort ist ein generischer Algorithmus, der lediglich einen Vergleichsoperator benötigt. Was am Ende durch Quicksort sortiert wird, ist dem Sortieralgorithmus auch egal.

Wenn man Algorithmen für Datentypen implementiert, bei denen die Datentypen für den Algorithmus egal sind, benötigt man Generics.

 

[Harry Kane]

Die wahre Stärke eines solchen Konstruktes wird erst deutlich, wenn du nicht jede Liste zu seinem eigentlichen Zielobjekt casten musst oder mit instance of prüfen musst, was den drin ist, um damit zu arbeiten.

Auch hilft es Fehler schon zur Compilezeit zu identifizieren und in der IDE entsprechende Empfehlungen zu geben, was eine Methode erwartet und wann.

Lieber Thallius, also für mich ist schon der erste Punkt ein ausreichender Grund, sich Generics mal zu Gemüte zu führen.
Ich habe vor 1.5 Jahren ein Projekt "generifiziert" und war positiv überrascht, wie viele instanceofs/Castings/Klammern auf einmal überflüssig wurden.

 

[Thallius]

W

Lieber Thallius, also für mich ist schon der erste Punkt ein ausreichender Grund, sich Generics mal zu Gemüte zu führen.
Ich habe vor 1.5 Jahren ein Projekt "generifiziert" und war positiv überrascht, wie viele instanceofs/Castings/Klammern auf einmal überflüssig wurden.

Ich habe doch nirgends gesagt das generics schlecht sind. Denn in Java hat man halt keine andere Wahl. Wer sich mal die Mühe macht über den Tellerrand von java hinaus sieht und dann feststellt wie einfach es sein kann Listen mit beliebigen Objecttypen zu implementieren wenn man eben einfach auf statische Typisierung verzichtet, dann mag man nie wieder sowas in Java implementieren.
Statische Typisierung stößt bei sowas nunmal an seine Grenzen. Um es trotzdem möglich zu machen werden dann solche vollkommen obskuren Konstrukteuren wie die java generics erfunden. Dabei müssten man einfach nur auf die statische Typisierung verzichten und schon ginge das mit ganz einfachen und syntaktisch und stylistisch eleganten Mitteln.

Gruss

Claus

 

[JavaMeister]

Ich habe doch nirgends gesagt das generics schlecht sind. Denn in Java hat man halt keine andere Wahl. Wer sich mal die Mühe macht über den Tellerrand von java hinaus sieht und dann feststellt wie einfach es sein kann Listen mit beliebigen Objecttypen zu implementieren wenn man eben einfach auf statische Typisierung verzichtet, dann mag man nie wieder sowas in Java implementieren.
Statische Typisierung stößt bei sowas nunmal an seine Grenzen. Um es trotzdem möglich zu machen werden dann solche vollkommen obskuren Konstrukteuren wie die java generics erfunden. .

Das hat allerdings nix mit statischer Typisierung oder den Mangel an möglichkeiten "beliebige" Objekte in einer Liste zu speichern. Denn trotz statischer Typisierung kann ich beliebige Objekte in einer Liste schreiben. Entweder ich gebe dort Object ein, "?" oder ich lasse die Angabe des generischen Typs weg. Dann bin ich bei Java 1.4 als es noch keine Generics in Java gab.

ABER: Ich möchte damit ja verhindern, per Definition, dass in einer Liste andere Objekte, als die die ich festlege eingefügt werden. Wieso ich das mache ist auch klar.

Man hat also alle Möglichkeiten.

Dabei müssten man einfach nur auf die statische Typisierung verzichten und schon ginge das mit ganz einfachen und syntaktisch und stylistisch eleganten Mitteln

Und damit auch auf alle Vorteile, die eine statische Typsierung bietet verzichten? Dann hätte man PHP, und das will niemand. Was wäre hier der Vorteil bei einer Liste?

 

[ceving]

Und damit auch auf alle Vorteile, die eine statische Typsierung bietet verzichten? Dann hätte man PHP, und das will niemand. Was wäre hier der Vorteil bei einer Liste?

Das wollen viele. Sonst gäbe es ja keine dynamischen Sprachen wie Scheme. Auch in Go wimmelt es vor interface{} Variablen. Und auch Java kennt Reflection und Proxies. Wenn man es sich leisten kann, sind dynamische Sprachen das praktischste überhaupt. Man muss sich nur darüber im Klaren sein, dass es Zeit kostet, wenn man den Typ zur Laufzeit analysieren muss.