Best Practice für kleine Variationen in gegebenen Modellklassen

[musiKk]

Hallo Forum,

ist nur eine kleine Frage. Mir geht es darum, dass verschiedene Modellklassen in verschiedenen Kontexten auch verschiedene Erweiterungen brauchen. Ein Beispiel: Ich bekomme Objekte von einem Web Service und stelle diese in einer Tabelle dar. Die Daten werden in den Spalten angezeigt und es gibt eine zusätzliche Auswahlspalte mit einer Checkbox, mit der man einzelne Zeilen aktivieren kann. Also braucht jede Zeile ein zusätzliches Attribut [c]checked[/c].

Wie würdet ihr das am besten angehen? Spontan fallen mir zwei Möglichkeiten ein:
1. Ein neues Objekt wird erstellt, welches beide Informationen enthält. In etwa

public class DataSelectIndicator {
	Data data;
	boolean selected;
}

2. Es wird vom alten Objekt geerbt und ein zusätzliches Attribut hinzugefügt:

public class SelectableData extends Data {
	boolean selected;
}

Vielleicht gibt es ja auch noch mehr. Das etwas nervige an beiden Varianten ist, dass wegen wegen solcher Kleinigkeiten immer neue Objekte erzeugt werden müssen und dann ist alles voll mit [c]ExtendedData[/c], [c]SelectableData[/c], [c]FooData[/c], ...
Vielleicht habe ich ja noch etwas offensichtliches übersehen. Vielleicht ist es ja auch Ok, nach einer der beiden Varianten vorzugehen und nur mir kommts komisch vor.

Danke schonmal
mK

 

[SlaterB]

public class SelectIndicator<T extends Data> {
    T data;
    boolean selected;
}

so zumindest nur eine Klasse bei verschiedenen Data-Arten

ansonsten vielleicht etwas Richtung
DataExtension<Boolean>
DataExtension<String>
..

 

[Gast2]

Du kannst auch in Data eine Liste mit einet neuer Klassen machen z.B. AttributeValue dann kannst soviele Value dynamsich reinschmeißen und befüllen und diese dann auswerten...

 

[musiKk]

@SlaterB
Ok, bei mir wechselt häufiger das, was in dem Beispiel [c]selected[/c] ist. Insofern könnte man das auch umgekehrt aufziehen...

public class ExtendedData<T> {
	Data data;
	T extension;
}

Tja, das ist das, was ich meine... in die Richtung habe ich gar nicht gedacht.

@SirWayne
Das wollte ich eigentlich vermeiden. Ich habe zwar mehr oder weniger Einfluss auf das Aussehen von beiden Seiten - also sowohl den Produzenten als auch den Konsumenten von Data -, aber das sollte dennoch möglichst entkoppelt sein. Schließlich kann potentiell jede Klasse eine solche Liste gebrauchen. Außerdem kann in Zukunft auch ein anderer Konsument hinzukommen (who knows...) und der braucht das vielleicht gar nicht.

Danke für die Antworten bisher.

 

[Wildcard]

Extension Object Pattern um zusätzliche Funktionalität auf einer Klasse bereitzustellen ohne das die Klasse davon betroffen wird:
TechJude: Extension Object Pattern : an Eclipse Example

 

[musiKk]

Sieht interessant aus. Ich werde aber wohl bei einer der andere Lösungen bleiben. Zum einen handelt es sich um reine Modelle ohne Interfaces und das Pattern scheint mehr auf Services abzuzielen. Wichtiger ist aber zum anderen, dass die Klassen generiert werden und da ist die Implementierung eines Interfaces nicht vorgesehen.
Gerade im Zusammenhang mit Eclipse ist das aber gut zu wissen.

 

[FArt]

Decorator ? Wikipedia

 

[Wildcard]

Ich werde aber wohl bei einer der andere Lösungen bleiben. Zum einen handelt es sich um reine Modelle ohne Interfaces und das Pattern scheint mehr auf Services abzuzielen.

Nein, das hat mit Services nichts zu tun. Das Pattern lässt sich auf jede Art Klasse anwenden.

Wichtiger ist aber zum anderen, dass die Klassen generiert werden und da ist die Implementierung eines Interfaces nicht vorgesehen.

Hört sich nach dem falschen Modelling Werkzeug an. Schonmal EMF angeschaut?

 

[musiKk]

Ich habe ein WSDL und brauche einen Service-Client (JAX-WS). Momentan wird der über [c]wsimport[/c] erzeugt. Wenn das mit EMF genauso einfach geht und mehr kann, dann von mir aus auch so, aber diesbezüglich habe ich nicht viel gefunden.

Angesehen habe ich mir das sonst aber nicht, weil Du das dermaßen oft erwähnst, dass mir die Einschätzung nicht objektiv vorkommt und wie ein goldener Hammer aussieht. Ist nicht böse gemeint, Deine restlichen Beiträge schätze ich schon.

 

[Wildcard]

Ich habe ein WSDL und brauche einen Service-Client (JAX-WS). Momentan wird der über wsimport erzeugt. Wenn das mit EMF genauso einfach geht und mehr kann, dann von mir aus auch so, aber diesbezüglich habe ich nicht viel gefunden.

Für JAX-WS gibt es AFAIK keinen Build-In Support. Texo geht wohl in diese Richtung, aber da kenne ich die Details nicht.

Angesehen habe ich mir das sonst aber nicht, weil Du das dermaßen oft erwähnst, dass mir die Einschätzung nicht objektiv vorkommt und wie ein goldener Hammer aussieht. Ist nicht böse gemeint, Deine restlichen Beiträge schätze ich schon.

Das hat einen einfachen Grund, EMF hat zwar mittlerweile einen sehr hohen Verbreitungsgrad (besonders in Europa), allerdings ist es nicht so verbreitet wie es aufgrund der Funktionalität eigentlich sein sollte. Da praktische jede Software Modelle enthält und EMF derzeit der Heilige Gral des Modellings ist, sollte EMF eigentlich in ca. 90% aller Java Software zum Einsatz kommen und da fehlt noch ein Stück...

 

[musiKk]

Für JAX-WS gibt es AFAIK keinen Build-In Support. Texo geht wohl in diese Richtung, aber da kenne ich die Details nicht.

Ok, mal schauen.

Das hat einen einfachen Grund, EMF hat zwar mittlerweile einen sehr hohen Verbreitungsgrad (besonders in Europa), allerdings ist es nicht so verbreitet wie es aufgrund der Funktionalität eigentlich sein sollte. Da praktische jede Software Modelle enthält und EMF derzeit der Heilige Gral des Modellings ist, sollte EMF eigentlich in ca. 90% aller Java Software zum Einsatz kommen und da fehlt noch ein Stück...

Nun gut, ich habe nur auch schon die Erfahrung gemacht, dass bedingungsloses Anpreisen schnell als "Fanboytum" abgestempelt und mit Ignoranz gestraft wird. Egal, wie die Fakten aussehen.

 

[Wildcard]

Nun gut, ich habe nur auch schon die Erfahrung gemacht, dass bedingungsloses Anpreisen schnell als "Fanboytum" abgestempelt und mit Ignoranz gestraft wird. Egal, wie die Fakten aussehen.

Da will ich dir gar nicht widersprechen, aber wenn ich mir überlege wie viele Mannmonate Entwicklung mir EMF in zahllosen Projekten mittlerweile gesparrt hat, finde ich es nur fair etwas zu 'evangelisieren'.
EMF und das Eclipse Modelling Ökosystem sind schon lange dort angekommen wo Microsoft schon seit Jahren versucht mit Projekt Oslo hinzukommen. Der Unterschied, Microsoft streicht Oslo immer weiter zusammen während Eclipse Modelling stetig wächst.