Java und die OOP

[Zet]

Hallo Leute,

ich scheine mit der OOP auf dem Kriegsfuß zu stehen, bzw. scheine sie einfach nicht zu verstehen.
Einige Diskussionen hier haben mich mal wieder auf das Thema blicken lassen, und alles was man meint richtig verstanden zu haben - scheint wieder falsch gewesen zu sein.

Mein Problem ist die zusammenhänge zu verstehen. Einfaches Beispiel Person:
Ich habe eine Klasse Person, von der die Klassen Mann und Frau erben.
Jetzt kann man:
- Person als normale Klasse erstellen, versorgen, und mann und frau von dieser erben lassen.
- Person als abstrakte Klasse modellieren, um sicherzustellen das die Unterklassen die Methoden ebenfalls implementieren und diese überschreiben. Dann ist es natürlich nichtmehr möglich ein konkretes Objekt der Klasse Person zu erstellen, was aber ja vermutlich (?) nie nötig sein wird. Außerdem wird die Polymorphie ein wenig verhindert?
- Person als Interface einbinden.

Doch anhand welcher Kriterien entscheidet ihr soetwas? Wann benutzt man was, auf welchem Wege und mit welchem Ziel.

Habe das Gefühl nachdem ich im OOP-Wald war, eine Lichtung entdeckt zu haben und anschließend im OOP-Dschungel gelandet zu sein...

 

[BRoll]

Wieso wird die Polymorphie verhindert wenn Person abstrakt ist?
Sie kann dann immer noch Mann oder Frau sein, bloß nicht eine implementierte Person (was dann aber ja der Sinn von Mann/Frau ist sowas zu geben).
Also wenn ich so bei meinen Projekten schaue, sind solche Superklassen meistens abstract,
da man diese nur als Überklasse verwendet, um mehreren unterklassen gleiche attribute/methoden mitzugeben.
Nicht abstrakt wird benötigt, wenn du eine "ganz normale" klasse hast, aber dann für besondere fälle eine angepasste
Version davon schreibst, die einige Methoden eben überschreibt und/oder erweitert. Dh. die alte Klasse wird immer noch irgendwo im Projekt verwendet, jedoch eine angepasste Version für eben den speziellen Zweck. Erst wenn es häufiger oder viele verschiedene Versionen eines Typs braucht, erstellt man dann normalerweise eine abstrakte Superklasse. Aber es kommt halt echt darauf an was du machen willst

 

[Zet]

Erstmal danke für deine Antwort!

Du hast recht, ich dachte in dem Sinne das man z. B. folgendes bei einer Abstrakten Oberklasse nicht machen könnte wäre die Polymorphie beeinträchtigt:

		Person[] personArray = new Person[]{new Mann(), new Frau()};

Ich habe schon etliche Mini-Projekte durch, in der Vererbung mit 1, 2 Klassen vorkam.
Ich glaube ein ordentliches OOP-Projekt, in dem alles vorkommt (Interfaces, Abstract, Vererbung ...) würde mir mal
ein Big-Picture geben.

Ein solches hatte ich leider bisher noch nicht...


Ich weiß, irgendwann macht es durch Übung hoffentlich Click, doch diese Standard Fahrzeug, Personen, ...-Übungen haben es bei meinem Sturkopf scheinbar noch nicht geschafft.

Hast du eine Idee für ein Projekt, oder Coding eines Projekt's, wo das nötig wäre?
Oder meinst du es wäre eine gute Idee sich ein Projekt auszudenken, und evtl das Forum regelmäßg nach Anregungen/Verbesserungen zu befragen? Oder fällt das dann schon unter Spam :bae:

Ich will, und muss das endlich mal auf die Kette kriegen :rtfm:

grüße
Zet

 

[BRoll]

Es müssen ja nicht unbedingt große Projekte sein, auch mit nur 10 Klassen kann man eine schöne Struktur bauen die viele Aspekte abdeckt.

Person[] personArray = new Person[]{new Mann(), new Frau()};

Wieso sollte das nicht funktionieren wenn Person abstrakt ist?
Wenn Person abstrakt ist funktioniert nur

Person person=new Person();

nicht. Wenn man aber ein neues Array anlegt, dann ist das "new Person[]"
ja kein Konstruktur in dem Sinn, sondern legt nur einen Container an,
indem dann eben die implementierten Konstruktoren von Mann und Frau
verwendet werden können.
(das merkt man ja auch daran dass ein objekt array immer mit null initalisiert ist)

Was auch helfen könnte, wären Unterlagen zu Clean Coding zu lesen.
Dort steht auch wann man was am ehesten macht, wie standardisierte
Interfaces, abstrakte Klassen usw. zu schreiben sind.
Vielleicht hilft dir die Beschreibung ja dann, wann etwas sinnvoll einzusetzen ist,
und noch wichtiger was denn am effizientesten wäre.

Obwohl man meistens ja eh nicht so viel Spielraum hat, in vielen Fällen gibt es eben
eine "gescheite" Lösung die im Sinne von OOP ist.
Weil ja auch Superklassen oder Interfaces eine bestimmte modifizierbarkeit und freiheiten bei der anwendung lassen, schon vom system der sprache her.
Daher merkt man eigentlich recht schnell wo ein Interface hingehört und wo nicht.
Weiterhin ist es noch abhängig von der Abstraktionstiefe und der Kapselungstiefe,
die du betreiben willst.
Ich finde man muss einen goldenen Mittelweg zwischen direkt Implementieren und Information Hiding finden.
Im krassesten implementierungs Fall => Alles in einer Klasse, damit ist OOP sowieso für die Katz und Java die falsche Sprache
Das Gegenteil wäre dann eine extrem Tiefe Abstraktionstiefe, bei der man sich erst durch meherer Klassen an Containern und Handlern durchwühlen muss, bis man mal auf ein Stückchen Implementierung stößt.
Allgemein sagt man ja, eine Klasse soll nur das machen, für was sie direkt zuständig und gedacht ist.
Und dann gibts natürlich noch verschiedene Modelle nach denen man sich orientieren kann,
zb. MVC.

Ich hoffe mal ich konte dir ein paar Anregungen geben

 

[Saheeda]

@Zet

Vielleicht hilft dir das ja zu entscheiden, wann sich was lohnt:

Abstrakte Klassen lohnen sich z.B. wenn eine Methode in allen oder den meisten Kindklassen gleich implementiert sein soll und nur in wenigen Ausnahmefällen anders. Im Ausnahmefall würdest du die Methode dann einfach überschreiben.


Beispiel: Fressen funktioniert bei fast allen Tieren gleich:

public abstract class Animal{

	private int lifepoints;

	public void eat(Food f){
		this.lifepoints += f.nutritionPoints;	
	}
}

public class Dog extends Animal{ ... }

public class Bird extends Animal { ... }

public class Fish extends Animal { ... }

Hier wäre es ziemlich nervig, das für jedes Tier einzeln zu schreiben. Erst recht, wenn du vielleicht was an der Implementierung ändern möchtest, weil dir ein besserer Weg eingefallen ist oder du mehr machen möchtest.


Hingegen funktioniert das Fortbewegen nicht gleich. Alle Tiere können sich irgendwie bewegen, aber wie ist anders. Du kannst über ein Interface sagen, _dass_ jedes Tier eine solche Funktion braucht, ohne die genaue Implementierung vorzugeben:

public interface Moveable{
	public void move(int x, int y);	
}

public class Dog extends Animal implements Moveable{

	public void move(int x, int y){
		//rennen
	}
}

public class Bird extends Animal implements Moveable{

	public void move(int x, int y){
		//fliegen
	}
}

public class Dog extends Animal implements Moveable{

	public void move(int x, int y){
		//schwimmen
	}
}

 

[Zet]

@Saheeeda, Danke erstmal für die Antwort und das Beispiel

In diesem Fall ist es doch egal ob die Klasse Animal Abstract oder nicht ist, oder?
Die erbenden Klassen können in beiden fällen die Methode eat entweder implementieren und somit spezialisieren, oder die der Basisklasse verwenden. Gezwungen werden sie in keinem der beiden Fälle zu etwas, oder?
Oder verstehe ich den Codeschnipsel grade falsch?


Das mit den Interfaces schau ich mir grade am Strategie-Pattern an, auch hier danke für dein Beispiel!

Lg
Zet

 

[Saheeda]

Du verstehst das schon richtig. Gezwungen irgendwas zu machen wird niemand. Dog, Fish und Bird benutzen einfach die eat()-Methode der Animal-Klasse. Das ist Sinn & Zweck von Vererbung: Kindklassen dürfen Methoden benutzen, die sie "einfach so" von ihrer Eltern-Klasse mitkriegen.
Jedes (reale) Tier weiß, dass es fressen muss. Nicht, weil es ihm irgendjemand gesagt hat, sondern weil's in seinen Genen verankert ist.
Genauso wie ein Mensch z.B. von seinen Eltern braune Haare erbt, ohne dass er sich selbst nochmal bewusst machen muss "Ich habe braune Haare." Du kannst deine Haare färben (=überschreiben), aber standardmäßig haben sie die geerbte Farbe.


Abstrakt, damit niemand auf die Idee kommt, ein Objekt "Animal" zu erstellen. Abstrakte Klassen lassen sich nicht instanzieren.
Probiers einfach mal:

Animal a = new Animal();