Schlagwort-Archive: oop

Merkhilfe für gutes Design

1) Switch-Konstrukte oder nicht-elementare if-Statements (alles, was nicht mit <,>=,==,|| etc geprüft wird)
weisen auf einen Design-Fehler hin, den man durch Polymorphismus lösen kann. Bsp: Methode male() vor und nach Benutzung von abstrakten Methoden
2) Vererbte Dinge sind immer in den Unterklassen da, aber nur public v/m sind echt “sichtbar”
3) Man verwendet immer private für Attribute einer Klasse und macht sich Getter/Setter um in Unterklassen (und evtl auch aus anderen Klassen) darauf zugreifen zu können
4) Vererben tut man, wenn verschiedene Objekte in Teilen gleich sind und sich gleich Verhalten
5) Abstrakte Klassen nutzt man, wenn es die Oberklasse an sich gar nicht gibt
6) Abstrakte Methoden nutzt man dann, wenn man vererben möchte, die Funktionalitäten aber in jeder Unterklasse anders implementiert werden müssen, und nicht gleich sind.
7) die Implementierung eines Interfaces ist sowas wie das Implementieren von abstrakten Methoden einer Superklasse, nur besser!

Gefunden hier:
Quelle: http://www.java-forum.org/einfuehrungen-erste-schritte/76834-vererbung-polymorphie.html

Delegation vor Vererbung

Vererbung ist ein tolles Mittel, um bereits modelliertes Verhalten vorhandener Klassen ohne Copy-Paste-Ansatz wiederzuverwenden. Jedoch eine Vererbung die nur dem Zweck dient, keinen Sourcecode zu duplizieren führt fast immer zu unsinnigen oder zumindest zweifelhaften Design und wird Implementierungsvererbung genannt. Die entstehende Klasse wiederspricht (in der Regel) dem Konzept des Subtyps. Gemeinsam verwendbare Funktionalität sollte besser in seperate Hilfsklassen ausgelagert werden und dann per Delegation statt Vererbung angesprochen werden.

Wird Vererbung nur eingesetzt, wenn tatsächlich die is-a Beziehung erfüllt ist, so profitiert man davon, dass beim Aufbau einer Klassenhierachie durch Ableitung lediglich die Unterschiede zum vererbten Verhalten und Zustand definiert werden müssen.

Delegation beschreibt, dass eine Aufgabe einem anderen Programmteil übergeben wird. In diesem Fall ist damit gemeint, das eine Klasse eine andere über eine Assoziation kennt und deren Methoden aufruft.

 

Quelle: “Auf dem Weg zum Java Profi” – Seite 50.

Siehe auch
http://clean-code-developer.de/Roter-Grad.ashx#Favour_Composition_over_Inheritance_FCoI_3

Gegen Schnittstellen, NICHT gegen Implementierungen programmieren

Wenn Sie gegen eine Schnittstelle programmieren, schreiben Sie bspw. List list = new ArrayList(); anstelle von ArrayList list = new ArrayList();, oder definieren als Parameter und Attribute Ihrer Methoden und Klassen keine konkreten Implementierungen, sondern lediglich die Interfaces List, Set, Map, Collection, …. Dies hat den Vorteil der höheren Generalisierung und Kompatibilität, aber auch den Nachteil von fehlenden Methoden und Funktionsweisen konkreter Klassen.

via :http://www.java-blog-buch.de/0802-die-collection-schnittstelle/

The main reason to do this is to decouple your code from a specific implementation of the interface. By writing your code like this:
Map data = new HashMap();
then the rest of your code only knows that data is a Map, which is good, because it you can now easily change to a different implementation of interface Map if necessary. You’d only need to change that one line of code, for example to:
Map data = new TreeMap();
For the rest of your program, nothing changes – data is still a Map.
If you would have written:
HashMap data = new HashMap();
then changing it would have been much harder, because the rest of your code might have used methods that are specific to HashMap.

via: JavaRanch