Sortiert programmieren?

[coco07]

Hey Community,

da mein Spiel fast fertig ist und ich durch den Code bereits nicht mehr durchsteige muss ich anfangen meine Programme besser zu unterteilen und sinnvolle Klassen erstellen.
Ich fange einfach mal damit an, dass ich eine Klasse Game habe, wo alle Spielgegenstände und Grafiken enthalten sind. Jeder Spielgegenstand ist ein Objekt und enthält die für sich wichtigen Attribute und Methoden. Da es z.B. die Methode draw() und delete() bei allen Spielgegenständen gibt, könnte ich hierfür sicher ein Interface nutzen? Sollte ich eine abstrakte Klasse für Spielgegenstände schreiben wo ich nur name und alter z.B drin speichere und dort auch das Interface implementiere oder lieber in den Unterklassen ?
Ich habe mal folgendes ausprobiert:

public static void main(String[] args) {
    	
    	GameObject gameObject = new Plant();
    	Plant plant = new Plant();
    	
        Game newGame = new Game(gameObject, plant);  
        
        newGame.mGameObject.draw();
        newGame.mGameObject.delete();
        newGame.mGameObject.test(); // Geht nicht
        
        newGame.mPlant.draw();
        newGame.mPlant.delete();
        newGame.mPlant.test();
    	  
    }

-GameObject ist eine abstrakte Klasse und enthält seinen Namen und implementiert drawable und deleteable.
- Plant ist ein GameObject und enthält eine Methode test()
- Game ist die Klasse, welche alle Spielgegenstände in einer Liste speichert und alles miteinander verknüpft.

Jetzt habe ich die Möglichkeit eine Schleife zu schreiben, wo alle Spielgegenstände welche gemalt werden können mit "instanceof drawable" zu malen:

ArrayList<GameObject> gameObjects = new ArrayList<GameObject>();
    	
    	Plant g1 = new Plant();
    	Plant g2 = new Plant();
    	
    	gameObjects.add(g1);
    	gameObjects.add(g2);
    	
    	for(Drawable d : gameObjects){
    		d.draw();
    	}

In einem anderen Forum wurde mir bereits erklärt immer die oberste Klasse als Typ zu verwenden und mit einem Objekt einer Kindklasse zu füllen. Ich verstehe allerdings nicht, warum das so sein soll. Im Code oben habe ich einmal ein GameObject und ein Plant, also einmal vom Typ der Oberklasse und einmal den Type der Klasse selber(was für mich durchaus sinniger erscheint) erzeugt.

Nun der Aufruf:

newGame.mGameObject.test()

funktioniert natürlich nicht, da GameObject nichts von der Kindklasse weiß.
Der Aufruf:

newGame.mPlant.test()

allerdings schon, da Plant über sich selbst Bescheid weiß(richtig ausgedrückt)?

Wo liegt hierin nun der Vorteil bzw. ist das wirklich richtig so?
In welchen Fällen sollte ich ein Interface nutzen und wie benutzen?
In welchen Fällen sollte ich den Typ der Oberklasse nehmen?

Die Aussagen im Buch von Galileo Computing sind etwas zu kompliziert...

grüße coco07!

 

[gescom]

Deine erste Frage verstehe ich nicht!

Ganz grob gesagt:
- Haben Objekte ein ähnliches Verhalten und eine Bindung zueinander verwendet man Vererbung.
- Bei unterschiedliche Typen die ähnliche Methoden implementieren verwendet man Interfaces.
- ...

Abstrakte Klassen können Methoden implementieren (müssen aber nicht). Interfaces sind dagegen eine Art "Vorschrift" was noch zu implementieren ist.

Falls dir eine Erklärung nicht verständlich erscheint, schaust du dir am besten eine andere Quelle an. Beispiele dafür sind genügend Vorhanden. :rtfm:
Falls dann noch etwas unklar ist fragst du hier im Forum.

 

[coco07]

Hey gescom,
danke für deine Hilfe
Wann man was benutzt ist mir relativ klar geworden.
Bei folgendem Codebeispiel aber habe ich kein Verständnis, dass man ein Objekt vom Typ "List" erstellt und nicht von "ArrayList"...

List<String> a = new ArrayList<String>();

Das hat wohl den Vorteil, dass ich in List alle Typen speichern kann, welche List implementieren. Das bedeutet, ich könnte auch dass hier machen und beide z.B zeitlich miteinander vergleichen:

List<String> b = new LinkedList<String>();

Aber wo genau liegt jetzt der Vorteil hingegen zu diesen Versionen:

ArrayList<String> c = new ArrayList<String>();
LinkedList<String> c = new LinkedList<String>();

Bei der obigen Version vom Typ List kann ich nur Methoden nutzen, welche das Interface List auch vorgibt, nicht aber von der Klasse ArrayList eigen mitgebrachte Methoden.
Bei der unteren Version kann ich alle Methoden nutzen, welche das Interface List vorgibt und alle selbst mitgebrachten Methoden der Klasse ArrayList...

Vielleicht ist das etwas ausführlicher

grüße coco07!

 

[njans]

Da du nur das Interface verwendest, kann die implementation dahinter ausgetauscht werden. Wenn du nun feststellst, dass deine Liste c nach einem Update deines Programmes schnell wächst und das zu Performance Problemen führt, dann kannst du schnell eine LinkedList daraus machen, ohne jedes Auftauchen dieser Liste von ArrayList zu LinkedList ändern zu müssen.

Generell kannst du dich auch fragen: Warum solltest du die expliziten Methoden von ArrayList anbieten, wenn du doch nur die Methoden brauchst, die List bereitstellt.

 

[coco07]

Hey njans,
erst einmal vielen Dank für deine Hilfe, habe auch soweit alles verstanden aber warum muss ich alles austauschen, wenn ich von ArrayList zur LinkedList Wechsel?
Beispiel:

ArrayList<Integer> a = new ArrayList<Integer>();
a.add(1);

Wenn ich jetzt eine LinkedList haben wollte, bräuchte ich nur den Typ ändern und ein anderes Objekt erzeugen:

LinkedList<Integer> a = new LinkedList<Integer>();
a.add(1); // Der Aufruf kann bestehen bleiben!

Hat das ganze vielleicht auch mit Performance zu tun, wenn ich einen kleineren Typen zur erzeugen des Objekts bereitstelle?

Auto a = new BMW(); // Bessere Performance?
BMW b = new BMW(); // Schlechtere Performance?

grüße coco07!

 

[turtle]

Werfe ich mal meinen Hut in den Ring

Was njans zu Recht anspricht (und wohl auch meint), ist Flexibilität.

Schreibst du die genaue Klasse hin (hier ArrayList) ist damit auch dein Code festgelegt.

Nimm an, das du eine Methode schreiben möchtest, die dir die Summe der Liste berechnet.
Du KANNST schreiben:

public Integer summe(ArrayList<Integer> list)

Du SOLLTEST aber schreiben

public Integer summe(List<Integer> list)

Entscheidest du dich mal, von ArrayList zu wechseln (aus welchem Grund auch immer), musst du an allen Stellen dies ändern.

Nehmen wir als änliches Konstrukt einen TextFileLogger, der Log-Ausgaben in eine Text datei schreibt. Aber auch hier legst du deinen Code fest und must jede Logausgabe in eine Textdatei machen.

Hast du dagegen ein Interface ILogger und der TextFileLogger implementiert dieses Interface, bist du viel flexibler. Du könntest einen anderen Logger schreiben, der das Interface (der Vertrag/Kontrakt) erfüllt und in der Implementierung es ganz anders macht (vielleicht in einer Datenbank ablegen/loggen).

Dein Code wird also durch die Programmierung gegen Interfaces VIEL flexibler.

 

[Joose]

..... wenn ich von ArrayList zur LinkedList Wechsel?
Beispiel:

ArrayList<Integer> a = new ArrayList<Integer>();
a.add(1);

LinkedList<Integer> a = new LinkedList<Integer>();
a.add(1);

Du musst jetzt in dieser Zeile an 2 Stellen das

ArrayList

durch

LinkedList

ersetzen.
Wenn du gegen das Interface programmierst dann musst du es nur an 1 Stelle ersetzen.

Bei einem kleinen Programm mit nur einer Klasse oder nur wenigen Methoden macht das kein Problem.
Aber in größeren Projekten wäre es Wahnsinn immer die direkten Implementierungen auszutauschen!

 

[coco07]

Hey Turtle,
vielen Dank, an die Methoden sowie Klassen habe ich gar nicht gedacht. Jetzt geht bei mir ein Lichtlein auf.. Ich danke dir!

Hey Joose,
denke das wird nicht das große Problem sein, eher das von Turtle angesprochene Problem. Trotzdem danke

Grüße coco07

 

[coco07]

Ich muss nochmals eben was fragen. Wieso ist List keine Klasse sondern ein Interface?
List ist für mich keine Eigenschaft sondern ein ganz normaler Gegenstand wie ein Auto...
Auch seltsam:
1. AbstractList >> implementiert List.
2. ArrayList >> extends AbstractList.
3. ArrayList >> implements List // Warum? Die Superklasse implementiert doch bereits List?

Im Grunde genommen ist doch hier Vererbung angebracht? Jede Klasse welche List implementiert IST EINE Liste. Und Warum eine Abstrakte Klasse schreiben, wenn die Subklassen eh alle Methoden überschreiben?

Das wäre doch so, als hätte ich ein Interface Auto und 2 Klassen BMW und Mercedes. Für mich wäre in diesem Fall Vererbung angesagt, weil BMW und Mercedes beides Autos sind. Warum also ein Interface und eine AbstractAuto Klasse schreiben? ???:L

grüße coco07!

 

[gescom]

Um mal beim Auto-Beispiel zu bleiben.
Ein Auto kann ja auch Komponenten/Funktionen besitzen die nicht zwingend nur Teil eines Autos sind.
In Java gibt es keine Mehrfachvererbung, es ist aber die Möglichkeit mehrere Interfaces zu implementieren.
Für mich macht es Sinn auch in den Unterklassen die zu implementierenden Interfaces anzugeben. Einerseits Behält man die Übersicht. Andererseits muss die Oberklasse nicht zwangsläufig alle Methoden des Interfaces auch fertig Implementiert haben.
Wieso gehst du davon aus das ALLE Methoden in den Unterklassen überschrieben werden? Die Vererbung findet doch statt... AbstractList -> ArrayList. Es gibt nun mal ein zusätzliches List Interface.

 

[turtle]

Für mich wäre in diesem Fall Vererbung angesagt, weil BMW und Mercedes beides Autos sind. Warum also ein Interface und eine AbstractAuto Klasse schreiben?

Das hat gescom schon richtig beantwortet, nämlich das es in Java keine Mehrfachvererbung gibt.

Dies hat aber auch die Konsequenz, das du nicht so ohne Weiteres eine Klasse "einfach" so von, (beispielsweise) Auto, erben lassen kannst, weil dadurch deine Klassenhierarchie zerstört würde.

Nehmen wir an, das du SW für einen Autozulieferer entwickelst und wahrscheinlich Klassen wie Zubehör, Fahrzeug, Teil. Nun kann aber dein BMW nicht mehr von Auto UND von Zulieferer::Fahrzeug erben, damit du es in deiner SW nutzen kannst. Dazu baut man ein Interface und kann es überall "einmixen", wo man es benötigt.

Leider müssen ja ALLE Methoden eines Interfaces implementiert werden. Dann schreibt man oft abstrakte Klassen, die die häufigsten Methoden bereits implementieren, so dass man nicht jedesmal eine Unmenge von Methoden schreiben muss.

In Java gibt es beispielsweise die abstrakte Klasse MouseAdapter, die viele Interfaces implementiert. Diese Implementierungen sind aber leer und erlauben es, von MouseAdapter zu erben, (wenn möglich) und nur wenige Methoden überschreiben zu können statt alle Interface-Methoden.