Welches Design besser?

[ethrandil]

Hi,
Wir programmieren gerade im InformatikLK (niveau? naja...) ein Programm zum anzeigen von Vektorgrafiken. Diese einzelnen Vektorbildchen kann man bewegen, rotieren, skalieren, pipapo...

Nun ist das Vorgesehene Modell in etwa so:

Abstrakte Klasse Vektorobjekt
_____________________________
||
\/
Abgeleitete Klasse z.B. Kreis
Im Vektorobjekt sind die ganzen Transformationen, eine abstrakte Methode liefert im Kreis die Form.

Ich habe aber ein anderes Design, dass ohne Abstrakte Klassen arbeitet. Nur mit einem Interface:

Interface Vektorobjekt Vektortransformer
______________________
||
\/
Implementierende Klasse, z.b. Kreis

Dabei habe ich ein Interface von einem Vektorobjekt, und übergebe dies einem Vektirtransformer!

Das sieht dann z.b. so aus:
Vektortransformer vt = new Vektortransformer(new Kreis());
vt.scale(5);
vt.show();

So - Was ist denn nun besser?
Mein Lehrer fand meine Methode unübersichtlicher. Das finde ich z.B: nicht ;)
Und er meint die bessere Kapselung (Form & Trransformation) in einzelne Klassen sei hier überflüssig.

Wie seht ihr das?

- Eth

[Lokadamus]

mmm...

Sourcecode ? sowohl von der "optimalen" Lösung als auch deiner ?

[ethrandil]

Ich kanns ja mal improvisieren.
"Muster":

public abstract class Grafikobjekt{

[...]

abstract public Shape getShape();

public void scale(double x){
[...]
}
public void draw(){
[...]
}
}

public class Kreis extends Grafikobjekt{
public Shape getShape(){
return new Ellipse.Double(...);
}
}


"Meins":

interface Vektorgrafik{
public Shape getShape();
}

public class KreisGrafik implements Vektorgrafik{
public Shape getShape(){
return new Ellipse.Double(...);
}
}

public class GrafikObjekt{
private Vektorgrafik vg;

[...]

public GrafikObjekt(Vektorgrafik vg){
this.vg = vg;
}

public void scale(double x){
[...]
}
public void draw(){
[...]
}
}

- Eth

[Aqualon]

Wenn du eine abstrakte Klasse verwendest hast du ja immer das Problem, dass du nur von dieser erben kannst und von keiner anderen Klasse.

Deswegen würde ich grundsätzlich die Verwendung von Interfaces der Verwendung einer abstrakten Klasse vorziehen, um dieses Problem von vornherein zu vermeiden.

Aqua

[Demirug]

ethrandil, die Antwort ist eigentlich ganz einfach.

Mach beides.

Definiere ein Interface und falls deine einzelnen Klassen genügend Gemeinsamkeiten bei der implementierung haben dann schreibe eine Basisklasse mit diesen Gemeinsamkeiten. Gibt es bei der Implementierung keine Gemeinsamkeiten kann man sich die Basisklasse natürlich sparen.

Auf diese Weise kannst du die Vorteile von beiden Techniken nutzen.

[Gnafoo]

Sorry .. kann jetzt nichts zum Thema beitragen, weil
ich kein Java kann, aber ich habe mal einige andere Fragen
aus reinem Interesse, wenn es dir nichts ausmacht :)

In welchem Bundesland gehst du zur Schule ? Und habt
ihr auch schon vor der Oberstufe Info gemacht ?

Ich geh in BaWü auf Gymi ..
Wir hatten mal ITG(Informationstech. Grundwissen) haben
da aber nur ein paar Pascal-Programme abgetippt
(wie sinnvoll) und ein bischen was mit Word gemacht ..
:banghead:

Und in der Oberstufe kann man Informatik als Wahlfach machen,
was einem aber nur eine zusätzlich eventuell einberechenbare
Note bringt. Als LK geht das zumindest nicht ..
Ich habs gewählt und es ist nicht zustande gekommen ..
wahrscheinlich, weil die Schule keinen Lehrer hatte der sich
damit auskennt..

Wie auch immer .. würde mich mal interessieren.
cya DerTod

PS: will auch :...(

[ethrandil]

Original geschrieben von Der Tod Und in der Oberstufe kann man Informatik als Wahlfach machen,
was einem aber nur eine zusätzlich eventuell einberechenbare Note bringt. Als LK geht das zumindest nicht ..
Ich habs gewählt und es ist nicht zustande gekommen ..
wahrscheinlich, weil die Schule keinen Lehrer hatte der sich damit auskennt..
Also, ich gehe in Hamburg zur Schule. Hier ist das so:

Es gibt Informatik wählbar ab der 11. Klasse. Da lernt man an einem abgespeckten Java-Programm die Basics von prozedualen Programmiersprachen. Ohne OOP.
Nach neuem Lehrplan lernt man auch Datenbanken.

In der Oberstufe kann man dann weiter Informatik wählen. AUch als LK. Wenn die Schule jedoch einen infoLK macht, dann braucht sie eine Sondergenehmigung dafür.

Der InformatikLK zählt jedoch zu keinem der 3 Hauptgruppen, die in den Prüfungsfächern vorkommen müssen! Das bedeutet, wenn man infoLK macht, dann kann man am ende nicht mehr ganz so frei die Prüfungsfächer wählen. Das ist bei mir aber kein Problem.

Wir lernen grade OOP mit BlueJ (www.bluej.org).

Wir haben schon php und Datenbanken gemacht und machen noch so ne funktionale programmiersprache :)

- Eth

[Xmas]

Ich habe irgendwie den Eindruck der gepostete Code entspricht nicht den Modellschemata...

Original geschrieben von ethrandil
Das sieht dann z.b. so aus:
Vektortransformer vt = new Vektortransformer(new Kreis());
vt.scale(5);
vt.show();
Diese Art der Kapselung finde ich ehrlich gesagt grausam. Zumindest solange der Vektortransformer keine Liste von Elementen hält, die alle gleichzeitig transformiert werden können. Ansonsten ist das nur eine weitere unnötige Ebene der Indirektion.

Ansonsten finde ich die sauberste Methode, ein Interface zu verwenden, das die Transformationen bietet, und dieses Interface bei jeder Shape-Klasse zu implementieren.

[ethrandil]

Original geschrieben von Xmas Diese Art der Kapselung finde ich ehrlich gesagt grausam. Zumindest solange der Vektortransformer keine Liste von Elementen hält, die alle gleichzeitig transformiert werden können. Ansonsten ist das nur eine weitere unnötige Ebene der Indirektion.

Ansonsten finde ich die sauberste Methode, ein Interface zu verwenden, das die Transformationen bietet, und dieses Interface bei jeder Shape-Klasse zu implementieren.
Es war so geplant, dass das Shape an sich nicht transformiert wird... d.H. Ein kreis bleibt ein kreis bleibt ein kreis *g*

Allerdings kann man den natürlich in die Breite ziehen, vergrößern o.ä. Das wäre eine Transformation.
Ich würde das jetzt, nach euren Tipps so machen, dass ich eine Transformationsklasse habe, die Vektorobjekte transformiert. Diese Klasse ist aber selber wiederum ein Vektorobjekt und kann auch nocheinmal transformiert werden.

So in Ordnung?

- Eth

[Xmas]

Also wenn du transformierst, "merkt" sich der Vektortransformer die Transformationen (mit einer Transformationsmatrix?) und wendet sie erst beim draw-Aufruf an? Hm, das ist ein interessantes Modell, gefällt mir aber aus dem Bauch heraus nicht.

Den neuen Vorschlag finde ich da besser. Im Grunde genommen kannst du dann sogar die Basiselemente zu Singletons machen.

[ethrandil]

Original geschrieben von Xmas
Also wenn du transformierst, "merkt" sich der Vektortransformer die Transformationen (mit einer Transformationsmatrix?) und wendet sie erst beim draw-Aufruf an? Hm, das ist ein interessantes Modell, gefällt mir aber aus dem Bauch heraus nicht.
joah. Hmm... Ist natürlich rechenaufwändiger...
Den neuen Vorschlag finde ich da besser. Im Grunde genommen kannst du dann sogar die Basiselemente zu Singletons machen.
Hmm, ja. Aber Singletons gefallen mir aus dem Bauch heraus nicht *gg*

Außerdem gibt es ja z.B. die Klasse Klaviergrafik, die über die Methode setTastenanzahl(int i) verfügt... nix Singeleton...

Ansonsten hast du das schon ganz gut verstanden, ja.
Ich vermute das ist Javaintern eine Trafomatrix, ja. Allerdings wird die in einem Objekt von Typ AffineTransform gekapselt, und mit scale(x,x) oder rotate(winkel, x, y) modifiziert.

- Eth

[Gast]

Die Lösung mit dem Interface ist in jedem Fall besser. Das Problem in Java ist, dass Java keine multiple Vererbung, wie z.B. C++, kennt. In C++ wäre die Lösung mit der abstrakten Oberklasse auch in Ordnung.

Das sich ein Vektorobjekt selber zeichnen kann, halte ich für einen Fehler. Darum finde ich Deinen Ansatz besser und flexibler, auch wenn er unübersichtlicher erscheint.