OOD / OOP - IS_A vs HAS_A

[schnitt_tt]

Hallo,

sicherlich ein alter Hut aber mit diesem Grundkonzept bzw wann wende ich welchen Fall an komm ich in der Desgin Phase einfach nicht zu Rande. (Bin Umsteiger aus der prozeduralen Programmierung).

Der Thread: "Modellierungsfrage zur Objektorientierung" hat mir auch nicht weitergeholfen, so wie das verstande habe, sollte man von den IS_A Beziehungen abstand halten. warum ? KA ;(

Also: Bsp 1

In meiner Anwendung betötige einen Button (JButton) mit dem ich eine Datei auswähle kann an 5 verschiedenen Stellen in der Anwendung. Damit ich diese "Funktionalität" nur einmal programmieren muß würde ich sagen:

MyButton = Spezialisierung von JButton, da JButton nicht das Verhalten mit sich bringt "wenn er gedrückt wird, erscheint ein POP-UP, Dateiauswahl, Prüfungen etc". -> das wäre dann eine IS_A Beziehung.
MyButton, ist ja vom Grunde her ein Button !. Daraus könnte ich nun ableiten, das ich eigentlich für jede Funktionalität eine eigene Buttonklasse erstelle müßte ... aehm ? das fühlt sich aber nicht richtig an. wie seht Ihr das ?

Also: Bsp 2

Es soll eine Übergreifende Klasse fürs Dateihandling enstehen. Im Prinzip gibt es wohl 2 Klasse:

a) DateiManager ( der enthält die eigentliche Logik -> Datei Laden, diverse Prüfungen etc)
b) DateiZeile ( Ein Objekt das als Datencontainer funktioniert)


als erstes würde ich wohl den DateiManger von einer Collection ableiten (IS_A) da ich ja eine variable Form der Zeilenspeicherung benötige. Aber mit Dateimanager = ArrayList hab ich so meine Bedenken, der Dateimanager ist Grundsätzlich ja eine "Collection", ???:L ???

Falls die DateiManager klasse lediglich eine HAS_A Beziehung zu einer Collection Klasse hätte würde sich das für Bauchmäßig besser anfühlen ...

gibt wohl kein einfaches Regelwerk um die Beziehungen abzugrenzen, oder ?

thx









Eigentlich würde ich einen eigenen Button erstellen

 

[diggaa1984]

In meiner Anwendung betötige einen Button (JButton) mit dem ich eine Datei auswähle kann an 5 verschiedenen Stellen in der Anwendung. Damit ich diese "Funktionalität" nur einmal programmieren muß würde ich sagen:

Zu dem Problem würde ich sagen: Erstelle dir einen ActionListener, welcher in der actionPerformed-Methode die jeweilige Logik anstößt (ob du alles direkt in den Listener schreibst, oder die Methode einer anderen Klasse dazu aufrufst spielt fürs Konzepte erstmal keine Rolle). Den Listener hängst du dann an jeden Button oder woran auch immer du möchtest um diese Funktion an der Stelle zu integrieren.

Aus Konzepttechnischer Sicht musst du ja nur die Funktion bei Button-Druck definieren, nicht aber ein neues Button-Objekt. Wenn du den nun rund oder trapezförmig darstellen möchtest, dann bietet sich an eine neue Klasse zu erstellen, so als Bsp.

 

[Kevin94]

Bsp 1: Wenn man in Java das Verhalten von Komponenten nur bei einer User-Eingabe ändern mochte, wie z.B. dem Button-Click benutzt man Listener, das wäre dann eine HAS A Beziehung: button HAS A ActionListener. Wenn verschiedene Buttons beim Click genau das selbe tun sollen meldet man bei allen den gleichen ActionListener an.
Bsp 2: Auch hier ist das Prinzip der Aggregation möglich, wie du auch zu bedenken gegeben hast. Man würde in dem Fall dies über eine Instanzvariable vom Typ List in der Klasse DateiManager realisieren. Aber es spricht auch nichts dagegen das deine Klasse das Interface List implementiert bzw. von ArrayList erbt.

Was die Frage wann was angeht, mach ich das meistens auch er aus Gefühl. Und auf Bsp1 bezogen gilt die allgemeine Regel: Man erbt nur dann von Swing/AWT Klassen wenn es nicht anders geht (Ausnahme: JPanel und JFrame),normalerweise setzt man die entsprechenden Listener und das UI mit entsprechenden eigenen Objekten.

 

[schnitt_tt]

@ diggaa1984

Aus Konzepttechnischer Sicht musst du ja nur die Funktion bei Button-Druck definieren, nicht aber ein neues Button-Objekt. Wenn du den nun rund oder trapezförmig darstellen möchtest, dann bietet sich an eine neue Klasse zu erstellen, so als Bsp.

"rund und trapezförmig" entspräche wohl der Spezialisierung eines JButtons, das leuchtet mir ein. Aber beim Verhalten ("Ich Button, mache etwas wenn ich gedrückt werde") hätte ich gedacht das dies auch eine Spezialisierung wäre ... hmmm ..

@Kevin94
gerade das "Gefühlmäßige" würde ich gerne mit einem begründbaren Regelwerk hinterlegen. dh im Fall x verwende ich nicht die Vererbung da Problem1, Problem2 .... etc Ist sicherlich oft Kontext abhängig, du sagst ja selbst bei Swing/AWT erbt man nur wenn es nicht anderst geht ... das muß ja einen Grund haben. -> Vermutung: das Verhalten der GUI-Elemente gibt eben SWING via Interfaces vor ...

bzgl. Bsp2:

Grundsätzlich könnte ich mir es ja einfach machen, alles was nach einer Collection aussieht (Irgendwelche xxxxxManager , xxxxHandler Klassen usw) immer stumpf von einer Collection ableiten, die notwendigen Methoden überschreiben und fertig ist die Laube .... aber mir wäre da ein gewisses Regelwerk doch lieber .... Im Sinne wenn, wenn eine Klasse erbt, dann diese Vorteile, aber auch diese Nachteile , das gleiche für Interface bzw Komposition .... (bitte kein Verweis auf diverse Bücher) ... denke wenn jemmand aus der Praxis kommt kann man das sicherlich hier darstellen ...

thx

 

[diggaa1984]

Aber beim Verhalten ("Ich Button, mache etwas wenn ich gedrückt werde") hätte ich gedacht das dies auch eine Spezialisierung wäre ... hmmm ..

Ok was macht ein button ohne das du etwas änderst? Einfach nur aussehen, aber sonst nichts ^^
Spezifische Funtionen bei "Klick" werden durch die ActionsListener definiert. Die werden bei Klick benachrichtigt und das wird dann die Funktion des Buttons.