OOP Wie sollte ich das organisieren (Abstract? Interface?)

javalampe

Mitglied
Hallo Freunde,

ich bin gerade am Organisieren meines Java Projektes und es würde mir sehr viel bei meinem Verständnis für OOP weiterhelfen, wenn ihr mir sagen könnt, was die beste Lösung für meine Klassen sind.

Man habe mehrere Fischklassen (Hering, Goldfisch, Hai, usw.) und dazu natürlich eine Mutterklasse Fisch.
Es gibt ein paar Methoden, also Fähigkeiten, die ich meine Fischklassen zwingen möchte zu besitzen, also zu implementieren. Darum dachte ich zuerst ich sollte ein Interface machen.
Dann gibt es aber ein paar Sachen, die möchte ich nicht in jeder Fischklasse neu schreiben. Also wäre eine Abstrakte Klasse doch besser oder nicht?

Ich würde mich sehr über schnelle Unterstützung freuen!
 

javalampe

Mitglied
Deine Überlegungen(Code)
Joa naja ich habs einmal als Interface geschrieben, dann zu Abstract umgewandelt und jetzt wieder beides rückgängig gemacht. Ist eher theoretisch :)

Java:
interface Fishy {...}
abstract class AbstractFish implements Fishy {...}
class GoldFish extends AbstractFish {...}
Das klingt gut! Ist das dann noch schön, macht man das so? :D Ich würds probieren.
 

Flown

Administrator
Mitarbeiter
Das klingt gut! Ist das dann noch schön, macht man das so? :D Ich würds probieren.
Deine Anforderungen sind:
- Es muss etwas implementiert werden per Contract. Ergo ein Interface.
- Es muss nicht immer alles neu implementiert werden. Ergo eine abstrakte Klasse mit vordefiniertem Verhalten, dass von einem Interface kommt.

Also ist das genau das Pattern das du brauchst.
 

temi

Top Contributor
Ergänzend sollte noch erwähnt werden, dass dein Vorhaben nach einer "partiell abstrakten Klasse" klingt. Das heißt alle Methoden, die in den Unterklassen identisch sind, werden in der abstrakten Basisklasse implementiert und alles was die Unterklassen selbst implementieren müssen sind auch in der Basisklasse abstrakte Methoden.
 

AndiE

Top Contributor
Habe ich jetzt einen Verständnisfehler? Wieso redet ihr von einer abstrakten Klasse? Vererbung spezialisiert doch die Klassen, habe ich immer gedacht. Also würde ich die gemeinsamen Anforderungen in der Super-Klasse implementieren, die dann mit den Sub-Klassen spezialisiert werden.
Beispiel: In die Super-Klasse Betriebsangehoeriger die Attribute Name, Vorname, Alter, Eintrittsdatum und die dazugehörigen Methoden. Die Sub-Klasse Arbeiter erbt von Betriebsangehoeriger und wird um Arbeitsstunden und Stundenlohn erweitert. Die Sub-Klasse Angestellter erbt ebenfalls von Betriebsangehoeriger und wird nur um Monatsgehalt erweitert.
 

mrBrown

Super-Moderator
Mitarbeiter
Habe ich jetzt einen Verständnisfehler? Wieso redet ihr von einer abstrakten Klasse? Vererbung spezialisiert doch die Klassen, habe ich immer gedacht. Also würde ich die gemeinsamen Anforderungen in der Super-Klasse implementieren, die dann mit den Sub-Klassen spezialisiert werden.
Beispiel: In die Super-Klasse Betriebsangehoeriger die Attribute Name, Vorname, Alter, Eintrittsdatum und die dazugehörigen Methoden. Die Sub-Klasse Arbeiter erbt von Betriebsangehoeriger und wird um Arbeitsstunden und Stundenlohn erweitert. Die Sub-Klasse Angestellter erbt ebenfalls von Betriebsangehoeriger und wird nur um Monatsgehalt erweitert.
Was ist denn deiner Meinung nach eine Abstrakte Klasse, wenn nicht eine Super-Klasse, die man durch Vererbung spezifiziert?
 

AndiE

Top Contributor
Eine abstrakte Klasse ist für mich eine Klasse, die nur die Methodensignaturen enthält aber im Gegensatz zum Interface auch Attribute besitzt. In einer abstrakten Klasse ins die Methoden auch mit "abstract" deklariert, in einer "normalen" Super-Klasse aber nicht.
 

temi

Top Contributor
Eine abstrakte Klasse ist für mich eine Klasse, die nur die Methodensignaturen enthält aber im Gegensatz zum Interface auch Attribute besitzt. In einer abstrakten Klasse ins die Methoden auch mit "abstract" deklariert, in einer "normalen" Super-Klasse aber nicht.
Das ist etwas zu schwarz/weiß gedacht (sorry, SchwarzWeiß, das ist nur Zufall ;))
In einer abstrakten Klasse müssen durchaus nicht alle Methoden abstrakt sein, das wird in der Praxis auch meist nicht der Fall sein.
 

AndiE

Top Contributor
Gegenfrage. Wenn ich bei der TDD zwei Klassen haben, die gemeinsame Funktionalität haben. Dann kann ich diese Funktionalität in eine neue Klasse ziehen, von der die beiden anderen erben. Habe ich dann eine "abstrakte Klasse" erstellt? Ich denke "nein". Wenn "Arbeiter und "Angestellter" von "Beschaeftigter" erben, dann kann ich letzteres doch auch für Methoden als Parameter anwenden und auch Instanzen von ihm bilden. In diesem Fall doch, wenn ich z.B. eine Liste des Krankenstandes anfertigen will. Dann ist es doch egal, wie er Geld bekommt.
 

mrBrown

Super-Moderator
Mitarbeiter
Wenn ich bei der TDD zwei Klassen haben, die gemeinsame Funktionalität haben. Dann kann ich diese Funktionalität in eine neue Klasse ziehen, von der die beiden anderen erben. Habe ich dann eine "abstrakte Klasse" erstellt?
Vererbung sollte durch die Domäne vorgegeben sein, und nicht aufgrund von gemeinsamen Codes erfolgen.

Aber ja, wenn ich es so lösen würde, hätte ich dann eine abstrakte Klasse.

Wenn "Arbeiter und "Angestellter" von "Beschaeftigter" erben, dann kann ich letzteres doch auch für Methoden als Parameter anwenden
Ja, auch wenn die abstrakt wäre.

und auch Instanzen von ihm bilden.
Ja, wenn es Beschäftigte gibt, die weder Arbeiter noch Angestellter sind und keinen Lohn bekommen, dann ginge das - alternativ böte sich da die Unterklasse "Sklave" an...


In diesem Fall doch, wenn ich z.B. eine Liste des Krankenstandes anfertigen will. Dann ist es doch egal, wie er Geld bekommt.
Ja, aber krank ist trotzdem ein Arbeiter oder ein Angestellter. Die geben kaum ihr Vorhandensein als dies aus, werden für eine kurze Zeit Beschäftigter, und verwandeln sich danach wieder zurück.


dynamischer vs statischer Typ ist dir aber schon bekannt?
 

AndiE

Top Contributor
@mrBrown, ich kann dir nicht folgen. Interfaces und abstrakte Klassen sollen nach meinem Wissen ähnliches bewirken. Und das ist, dass sie Methoden vorgeben, die in Klassen, die davon erben oder sie einbinden, ausprogrammiert werden müssen. Sie sind also theoretisch Pausvorlagen für Klassen, die ja wiederum Pausvorlagen für Objekte sind. Wie hier schon geschrieben wurde, meine ich, dass abstrakte Klassen nur beerbt werden können, aber aus ihnen keine Instanzen gebildet werden können. Das ist bei Interfaces eben anders.
 

mrBrown

Super-Moderator
Mitarbeiter
Wie hier schon geschrieben wurde, meine ich, dass abstrakte Klassen nur beerbt werden können, aber aus ihnen keine Instanzen gebildet werden können. Das ist bei Interfaces eben anders.
Aus Interfaces können auch keine Instanzen gebildet werden?

Der Unterschied ist, dass das eine eine Klasse und das andere ein Interface ist, und das es als Klasse eben Instanzattribute haben kann.
 

AndiE

Top Contributor
Code:
class Person{

private String name;

public String getName(){
  return this.name;
}

public void setName(String name1){
  this.name=name1;
}

};

class Arbeiter extends Person{

private double einkommen;

public void setEinkommen(double eink){
this.einkommen= eink;
}

public double getEinkommen(){
  return this. einkommen;
}

};

class Verwaltung{

static void main(){

Arbeiter a= new Arbeiter();
a.setName("Hans");
a.setEinkommen(1000.0);
}

};

Ich habe das mal als Beispiel erstellt. Für mich ist Person keine abstrakte Klasse. Warum sollte sie eine sein? Das war meine Frage.
 

mrBrown

Super-Moderator
Mitarbeiter
Hat auch niemand gesagt, dass man zwingend eine abstrakte Klasse draus machen muss...aber es muss eben auch keine normale sein.
Und für die Ursprungsfrage wäre es besserer Stil.
 

temi

Top Contributor
Ich versuche mal ein Beispiel, leider ist mir auf die Schnelle nichts besseres eingefallen:
Java:
public interface LogInterface
{
    void logError(String errorstr);
}

public abstract class AbstractFileLogger implements LogInterface
{
    public void setFileName(String fileName)
    {
        // code
    }

    public abstract void logError(String errorstr);
}


public class SimpleFileLogger extends AbstractFileLogger
{
    @Override
    public void logError(String errorstr)
    {
        // code
    }
}

public class FormattingFileLogger extends AbstractFileLogger
{
    @Override
    public void logError(String errorstr)
    {
        // code
    }
}

public class SomeClass
{
    private LogInterface logger;

    // die konkrete Implementation des Loggers ist nicht relevant...
    public SomeClass(LogInterface logger)
    {
        this.logger = logger;
    }


}

public static main()
{
    SimpleFileLogger logger = new SimpleFileLogger();
    logger.setFileName("simple.log");
  
    SomeClass someInstance = new SomeClass(logger);

    // weiterer Code

}

Das Interface legt fest, dass es eine Methode zum Loggen eines Strings geben soll.
In der abstrakten Klasse, werden Methoden implementiert, die die Verwaltung einer Datei in irgendeiner Weise vornehmen. Davon wiederum erben zwei konkrete Implementation für einen einfachen Logger, der den Text unformatiert in die Datei schreibt und eine zweite, die vorher noch irgendwelche Formatierungen vornimmt. Im eigentlichen Programm verlangen wir nur eine Klasse, die das Interface implementiert und sind dort von der konkreten Programmierung dieser Klasse unabhängig.
Es könnte irgendwann noch einen AbstractDatabaseLogger usw. geben, in der Klasse "SomeClass" ist keine weitere Anpassung dafür notwendig. Das ist der (oder ein) Sinn von Interfaces....
 

javalampe

Mitglied
Hui hier hat sich ja einiges getan. Ihr seid jetzt in ne Diskussion über allgemeine Objektorientierung abgerutscht :p Ich würde gerne mal zu meinem konkreten Superklasse Fish, Subklassen HerringFish, PufferFish, SharkFish, usw. zurückkehren.
Nochmal zusammengefasst: Ich brauchte eine Lösung, bei der nur die Subklassen instanziierbar sind. Gleichzeitig gibt es Methoden, die jeder der Subklassen haben sollte.
Ihr empfahlt mir ein Interface (IFish), welche von einer abstrakten Superklasse Fish implementiert wird. Darauf habe ich jetzt die letzten Tage mein Programm aufgebaut.

Das ist nun etwas hässlich bei mir geworden. Ich meine ich kann damit leben, aber ich bin nicht sicher ob das im Sinne der OOP ist, was ich da gemacht habe.

Meine Subklassen siehen alle aus wie folgt:
HerringFish.java
Java:
public class HerringFish extends Fish {

    private static final int animationSpeed = 2000;
    private static final int price = 50;

    @Override
    public void spawn() {
        super.spawn("hering.png", 120, 41);
        super.animate(animationSpeed);
    }

    public static int getPrice() {
        return price;
    }

    public void special() {
        super.special(animationSpeed, 350, 410);
    }

}

Ziemlich arm. Imgrunde unterscheiden sich die Fische (Subklassen) nur durch ihre Konfiguration. Das heißt ich gebe immer nur seine Attributwerte an die Methoden der Superklasse weiter.

Java:
public interface IFish {

    void spawn(String imagePath, int width, int height);
    void animate(int speed);

    static int getPrice() {
        return 0;
    }

    void die();
    Node getNode();

}

Java:
public abstract class Fish implements IFish {

    protected ImageView iv;
    protected double currentX;
    protected double currentY;
    protected PathTransition animation;

    public void spawn() {}

    @Override
    public void spawn(String imagePath, int width, int height) {
       Image image = new Image("/mia/res/img/" + imagePath);
       iv = new ImageView();
       // code code code
    }

    public void special() {}

    public void special(int animationSpeed, int pipeX, int pipeY) {
        // code code code
    }

    @Override
    public void animate(int speed) {
        animation = new PathTransition();
        // code code code
        animation.play();
    }

    public void stopAnimation() {
        animation.stop();
    }

    private Path createPath() {
        Path path = new Path();
        // code code code
        return path;
    }

    @Override
    public void die() {
        animation.stop();
        iv.setImage(null);
    }

    @Override
    public Node getNode() {
        return iv;
    }

    private Path createPathToSpecial() {
        Path path = new Path();
        // code code code
        return path;
    }

}

In der Fish.java war ich dann immer wieder gezwungen 2x die gleiche Methode zu erstellen. Einmal die Methode mit dem eigentlichen Code (wie special(...) oder spawn(...)), die eben nur mit den Attributen der Subklasse funktionieren, welche ich halt als Parameter übergeben muss. Und dann muss ich die Methode mit dem gleichen Namen nochmal erstellen mit ohne Parameter und leer. Dies einfach aus dem Grund, dass ich im Programmcode nicht weiß mit welcher Fisch Subklasse ich es zu tun habe, und die Objekte als Fish deklariere. Es wäre mir nicht erlaubt auf diese Objekte .spawn() oder .special() auszuführen, wenn es diese Methode in der Fish Klasse nicht gibt.

Versteht ihr mich? Man ich steh total auf dem Schlauch... :(
 

mrBrown

Super-Moderator
Mitarbeiter
Ziemlich arm. Imgrunde unterscheiden sich die Fische (Subklassen) nur durch ihre Konfiguration. Das heißt ich gebe immer nur seine Attributwerte an die Methoden der Superklasse weiter.
Das wäre dann ein Grund, keine eigenen Klassen zu erstellen, sondern nur eine Klasse Fish ;)

In der Fish.java war ich dann immer wieder gezwungen 2x die gleiche Methode zu erstellen. Einmal die Methode mit dem eigentlichen Code (wie special(...) oder spawn(...)), die eben nur mit den Attributen der Subklasse funktionieren, welche ich halt als Parameter übergeben muss. Und dann muss ich die Methode mit dem gleichen Namen nochmal erstellen mit ohne Parameter und leer. Dies einfach aus dem Grund, dass ich im Programmcode nicht weiß mit welcher Fisch Subklasse ich es zu tun habe, und die Objekte als Fish deklariere. Es wäre mir nicht erlaubt auf diese Objekte .spawn() oder .special() auszuführen, wenn es diese Methode in der Fish Klasse nicht gibt.
Das klingt sehr, sehr falsch...

Das Interface sollte ALLE Methoden definieren, die alle Fische haben und die sichtbar sein sollen.

Die abstrakte Klasse definiert alle Attribute, die alle Fische haben, und implementiert alle Methoden, die nur diese Attribute nutzen. Für die Attribute gibt es entweder Setter, oder sie werden im Konstruktor gesetzt.

Die Unterklassen definieren dann Methoden und Attribute, die NUR jeweils sie selbst brauchen, und implementieren alle Methoden, die in der abstrakten Klasse nicht implementiert werden konnten.


In deinem Fall kann bereits alles in der Abstrakten Klasse implementiert werden, da sie sich nur in den Werten unterscheiden - du brauchst also nur Interface und Implementierung dessen.
 

javalampe

Mitglied
Das wäre dann ein Grund, keine eigenen Klassen zu erstellen, sondern nur eine Klasse Fish ;)
Ja das stimmt. Aber ich hab ganz feste vier Fischtypen und dafür will ich allein schon aus Prinzip eigene Klassen. Das ist, ich weiß nicht ob ichs erwähnt hab, ein Hochschulprojekt wo Wert auf objektorientierte Strukturen gelegt wird. Ich möchte mir offen halten, für die Fischtypen besondere Eigenschaften oder Fähigkeiten einzubauen, was ich auch noch machen werde.


Die abstrakte Klasse definiert alle Attribute, die alle Fische haben, und implementiert alle Methoden, die nur diese Attribute nutzen. Für die Attribute gibt es entweder Setter, oder sie werden im Konstruktor gesetzt.
Argh... du öffnest mir die Augen. Ich kann ja die ganzen Attribute in der Fish.java haben und einfach im Konstruktor der Subklassen diese Attribute konfigurieren. (facepalm)

Die Unterklassen definieren dann Methoden und Attribute, die NUR jeweils sie selbst brauchen, und implementieren alle Methoden, die in der abstrakten Klasse nicht implementiert werden konnten.
Wie meinst du das. Ich kann doch wenn ich in einem Interface Methoden vorschreibe, doch nicht diese in der implementierenden Klasse NICHT implementieren und stattdessen dafür in einer von dieser erbenden?

In deinem Fall kann bereits alles in der Abstrakten Klasse implementiert werden, da sie sich nur in den Werten unterscheiden - du brauchst also nur Interface und Implementierung dessen.
Also wie ich oben erklärt habe, werde ich die Subklassen doch beibehalten. Aber ich stell diese Fragen trotzdem noch für mein OOP Verständnis.
Wieso würde ich ein Interface machen, wenn ich nur eine implementierende Klasse habe. Wieso mache ich die eine einzige Klasse die ich brauche nicht einfach so wie ich sie haben will?
Wieso habe ich das überhaupt, auch wenn ich die Subklassen habe, so gemacht? Wieso habe ich die abstrakte Klasse nicht einfach gebaut wie ich sie wollte? Sorry, mein Kopf arbeitet gerade nicht so gut.

Vielen Dank für deine schnelle Antwort, sie war wirklich sehr aufschlussreich.
 

mrBrown

Super-Moderator
Mitarbeiter
Ja das stimmt. Aber ich hab ganz feste vier Fischtypen und dafür will ich allein schon aus Prinzip eigene Klassen. Das ist, ich weiß nicht ob ichs erwähnt hab, ein Hochschulprojekt wo Wert auf objektorientierte Strukturen gelegt wird. Ich möchte mir offen halten, für die Fischtypen besondere Eigenschaften oder Fähigkeiten einzubauen, was ich auch noch machen werde.
Also ich als Bewertender würde für unnötige eigene Klassen Abzüge geben ;P

Wie meinst du das. Ich kann doch wenn ich in einem Interface Methoden vorschreibe, doch nicht diese in der implementierenden Klasse NICHT implementieren und stattdessen dafür in einer von dieser erbenden?
In der abstrakten Klasse müssen die Methoden aus Interfaces nicht implementiert sein, erst in der konkreten Klasse.

Wieso würde ich ein Interface machen, wenn ich nur eine implementierende Klasse habe. Wieso mache ich die eine einzige Klasse die ich brauche nicht einfach so wie ich sie haben will?
Wieso habe ich das überhaupt, auch wenn ich die Subklassen habe, so gemacht? Wieso habe ich die abstrakte Klasse nicht einfach gebaut wie ich sie wollte? Sorry, mein Kopf arbeitet gerade nicht so gut.
Wie soll ich dir denn beantworten, warum du die Klassen nicht so gemacht hast, wie du wolltest? :p
 

javalampe

Mitglied
Also ich als Bewertender würde für unnötige eigene Klassen Abzüge geben ;P

Also wie gesagt :) Ich schau schon noch, dass die Fische noch Spezialfähigkeiten bekommen.

In der abstrakten Klasse müssen die Methoden aus Interfaces nicht implementiert sein, erst in der konkreten Klasse.
Ja? Das glaub ich erst wenn ichs ausprobiert hab :D Ja ne wenn dus sagst, ok^^

Wie soll ich dir denn beantworten, warum du die Klassen nicht so gemacht hast, wie du wolltest? :p

Na das war euer Vorschlag. Also auf der ersten Seite des Threads haben das mehrere gemeint. Und ich muss es damals ja auch irgendwie für sinnvoll erachtet haben.
 

Meniskusschaden

Top Contributor
Also wie gesagt :) Ich schau schon noch, dass die Fische noch Spezialfähigkeiten bekommen.
Das ist aber eine ziemlich schräge Vorgehensweise. Du willst unbedingt eigene Klassen pro Fischart, also denkst du dir irgend etwas aus, damit das sinnvoll erscheint. Das kann leicht zu einem großen Reinfall werden, denn Anfänger neigen dazu, viel zu sehr auf Vererbung und verschachtelte Klassenhierarchien zu setzen. Woher weißt du denn jetzt schon, dass diese Spezialfähigkeiten überhaupt eigene Fisch-Unterklassen erforderlich machen? Vielleicht wäre ja auch eine Spezialfähigkeitsklasse pro Spezialfähigkeit besser. Was machst du, wenn mehrere Fischsorten dieselbe Spezialfähigkeit haben?
Es ist doch erst einmal ein Riesenproblem, wenn man pro Fischsorte eine eigene Klasse hat, weil man dann kaum jemals alle Fischsorten unterstützen kann. Solche Einschränkungen würde ich lieber vermeiden.
 

javalampe

Mitglied
Die letzten zwei Sätze habe ich nicht verstanden, kannst du das bitte nochmal erklären?

Es ist einfach so. Das ganze Programm besteht aus einem Aquarium und einem Shop. Da gibt es vier verschiedene Fischarten zu kaufen. Die Fische sind was das ganze Spiel ausmachen. Es gibt fast nur sie. Da möchte ich schon eigene Klassen haben. Wir haben noch viel Zeit für das Projekt und ich möchte mir die Möglichkeit offen halten noch ganz verrückte Dinge mit den Fischen anzustellen und da ist es mir lieber ich habe die Fischarten in separaten Klassen. Ich mein die Alternative wäre doch ich instanziiere meine Heeringe als Fish mit einem Parameter "Heering" oder als Enum wie auch immer (Wie würdet ihr das denn machen, mal so aus Interesse). Und new Fish("Herring") zu machen, wo es 4 konkrete Fischarten gibt und diese das halbe Spiel ausmachen, finde ich einfach sehr unästhetisch.
Da neige schon irgendwie echt dazu Spezialfähigkeiten für die Fische zu erfinden damit das mehr Sinn macht. Was natürlich eine komische Vorangehenweise ist. Aber unter dem Aspekt, dass es nur ein Schulprojekt ist und wir programmieren können was immer wir wollen, passe ich mein Programm halt der objektorientierten Struktur meiner Wahl an, anstatt andersrum. :confused:
 

javalampe

Mitglied
Die letzten zwei Sätze habe ich nicht verstanden, kannst du das bitte nochmal erklären?

Es ist einfach so. Das ganze Programm besteht aus einem Aquarium und einem Shop. Da gibt es vier verschiedene Fischarten zu kaufen. Die Fische sind was das ganze Spiel ausmachen. Es gibt fast nur sie. Da möchte ich schon eigene Klassen haben. Wir haben noch viel Zeit für das Projekt und ich möchte mir die Möglichkeit offen halten noch ganz verrückte Dinge mit den Fischen anzustellen und da ist es mir lieber ich habe die Fischarten in separaten Klassen. Ich mein die Alternative wäre doch ich instanziiere meine Heeringe als Fish mit einem Parameter "Heering" oder als Enum wie auch immer (Wie würdet ihr das denn machen, mal so aus Interesse). Und new Fish("Herring") zu machen, wo es 4 konkrete Fischarten gibt und diese das halbe Spiel ausmachen, finde ich einfach sehr unästhetisch.
Da neige schon irgendwie echt dazu Spezialfähigkeiten für die Fische zu erfinden damit das mehr Sinn macht. Was natürlich eine komische Vorangehensweise ist. Aber unter dem Aspekt, dass es nur ein Schulprojekt ist und wir programmieren können was immer wir wollen, passe ich mein Programm halt der objektorientierten Struktur nach Wunsch an, anstatt - wie es üblich wäre - andersherum.
 

Meniskusschaden

Top Contributor
Die letzten zwei Sätze habe ich nicht verstanden, kannst du das bitte nochmal erklären?
Meinst du diese beiden Sätze?:
Es ist doch erst einmal ein Riesenproblem, wenn man pro Fischsorte eine eigene Klasse hat, weil man dann kaum jemals alle Fischsorten unterstützen kann. Solche Einschränkungen würde ich lieber vermeiden.
Damit meine ich, dass du für jede zusätzliche Fischart eine neue Klasse programmieren müsstest, was nicht nötig wäre, wenn du nur eine Fischklasse hättest, die du entsprechend konfigurierst. Das hätte auch den Vorteil, dass dein Code solange universell bleibt, bis du an Grenzen kommst. Dann kannst du immer noch die Klassen einführen, die du zur Problemlösung wirklich brauchst und hast auch automatisch eine Begründung dafür (bisher sind das ja eher emotionale als technische Begründungen gewesen;)). Es ist nicht sinnvoll, Lösungen einzubauen, für die man das passende Problem noch nicht kennt.

und ich möchte mir die Möglichkeit offen halten noch ganz verrückte Dinge mit den Fischen anzustellen
Inwiefern verbaust du dir denn etwas, wenn du eine Klasse erst dann einführst, wenn du eine konkrete Begründung dafür hast? Solange du noch keine Vorstellung davon hast, was das für verrückte Sachen sein sollen, kannst du doch auch nicht wissen, wie die geeignete Klassenhierarchie aussieht. Vielleicht ist das ja wirklich eine, die eine Klasse pro Fischart erfordert, aber aus den bisherigen Informationen lässt sich das meines Erachtens noch nicht ableiten.

Unter'm Strich wäre es eben sinnvoller, wenn du zunächst festlegst, was in deinem Spiel eigentlich passieren soll und dann die passenden Klassen festlegst. Wenn die Klassenhierarchie für dich sowieso schon fest steht, ist die Frage nach einer Empfehlung eigentlich auch sinnlos, denn du bist offenbar auf der Suche nach einer Aufgabenstellung, die zu der von dir gewünschen Klassenhierarchie passt.
 

javalampe

Mitglied
Ja ne da habt ihr natürlich recht^^ Ich bestehe nur deshalb so sehr auf die Fischtypen-Klassen, da es ja immer noch ein Uni-Projekt ist und ich so Dinge wie Interfaces, abstrakte Klassen und erbende Klassen drin haben möchte bzw. auch muss. Deshalb pass ich das Spiel halt etwas daran an :p Aber ist ok, ich bin zufrieden damit wie es gerade ist. Danke euch!
 
Ähnliche Java Themen
  Titel Forum Antworten Datum
monsterherz Fehler Semikolon fehlt - ich weiss aber nicht wo da noch eines hin sollte... Java Basics - Anfänger-Themen 21
A Wie sollte ich es am besten an gehen - denkweise Java Basics - Anfänger-Themen 48
J Vektoren Add gibt nicht das aus was es sollte Java Basics - Anfänger-Themen 3
M Klassen Warum sollte man Abstraktion verwenden? Java Basics - Anfänger-Themen 4
W Dezimalzahl in Binär umwandeln - Was sollte ich an meinem Programm verbessern? Java Basics - Anfänger-Themen 5
C Polymorphie Was genau ist Polymorphie und wann genau sollte man es verwenden? Java Basics - Anfänger-Themen 9
S Erste Schritte Generische Klassen sind toll ....aber warum sollte ich das je benutzen? Java Basics - Anfänger-Themen 3
W Wie kann man diesen Code in einen Code umwandeln, der folgendes können sollte? Java Basics - Anfänger-Themen 1
S Welchen Bereich sollte ich favorisieren? Java Basics - Anfänger-Themen 3
K JAR Dateien einbinden - funkt nicht wie es sollte... Java Basics - Anfänger-Themen 22
S JUnit assertEquals funktioniert nichgt wie es sollte :( Java Basics - Anfänger-Themen 7
L Erste Schritte Sollte ich hier lieber Cases verwenden oder wäre eine If-Bedingung besser? Java Basics - Anfänger-Themen 6
P Ergebnis sollte double sein ... Java Basics - Anfänger-Themen 5
S Wie sollte man Package bezeichnen Java Basics - Anfänger-Themen 2
B Frage zu Programmierstil: sollte Hauptklasse nur main enthalten? Java Basics - Anfänger-Themen 6
D Warum sollte ich bestehende Funktionen "extend"en? Java Basics - Anfänger-Themen 32
B String Array funzt nich wie sollte Java Basics - Anfänger-Themen 3
G Sollte man Klassenvariablen als final deklarieren? Java Basics - Anfänger-Themen 3
C Sollte man dies kapseln? Java Basics - Anfänger-Themen 4
D Objektorientierung - wie konsequent sollte man sein ? Java Basics - Anfänger-Themen 30
J Methoden Zwei Methoden die fast das gleiche tun organisieren Java Basics - Anfänger-Themen 3
MiMa Code Organisieren Java Basics - Anfänger-Themen 7
S Richtlinien wie man Classen in Packages organisieren soll? Java Basics - Anfänger-Themen 3
B Datentypen Wie Daten am besten organisieren? Java Basics - Anfänger-Themen 7
C Wie Threads im Spiel organisieren ? Java Basics - Anfänger-Themen 2
S Organisieren von Konstanten Java Basics - Anfänger-Themen 16
N Datenmodell -> wie organisieren Java Basics - Anfänger-Themen 2
Say abstract class und Objekt erzeugen - Dringend Hilfe Java Basics - Anfänger-Themen 10
S Wann Methode abstract? Java Basics - Anfänger-Themen 10
O Verständniss Problem bei abstract class Java Basics - Anfänger-Themen 7
H abstract und interface Java Basics - Anfänger-Themen 4
H abstract - Wozu? Java Basics - Anfänger-Themen 6
B Interface vs Abstract Java Basics - Anfänger-Themen 2
B Objekte zählen/ Vererbung/ Kopplung/ Interface/ Abstract Class Java Basics - Anfänger-Themen 5
W Vererbung, abstract und Konstruktoren Java Basics - Anfänger-Themen 30
Azazel Ist die abstract class das selbe wie ein interface ? Java Basics - Anfänger-Themen 33
S Compiler-Fehler not abstract and does not override Java Basics - Anfänger-Themen 9
M abstract method does not override or implement.... Java Basics - Anfänger-Themen 7
B Fehler : class is abstract and does not overwrite Java Basics - Anfänger-Themen 2
B klasse abstract Java Basics - Anfänger-Themen 9
R Wofür abstract? Java Basics - Anfänger-Themen 29
E Klasse abstract machen Java Basics - Anfänger-Themen 3
G Schlüsselworte Bedeutung von abstract Java Basics - Anfänger-Themen 2
C Liste mit Attribut Abstract vererben Java Basics - Anfänger-Themen 11
Y Theorie: Abstract Method Java Basics - Anfänger-Themen 6
P Problem mit Eclipse "must be declared as abstract" Java Basics - Anfänger-Themen 3
O Abstract Method & Generics Java Basics - Anfänger-Themen 10
B abstract static Java Basics - Anfänger-Themen 16
T abstract class Java Basics - Anfänger-Themen 8
K abstract Java Basics - Anfänger-Themen 8
W abstract static Java Basics - Anfänger-Themen 3
F does not overwride abstract method Java Basics - Anfänger-Themen 2
G Verständnisfrage zum Interface und Abstract Java Basics - Anfänger-Themen 3
A in abstract Klasse private Variablen Java Basics - Anfänger-Themen 3
J abstract & Polymorphismus Java Basics - Anfänger-Themen 11
K Problem mit Abstract Table Model Java Basics - Anfänger-Themen 5
D Fehlermeldung "Time is not abstract" Java Basics - Anfänger-Themen 6
T Problem mit Abstract Windowing Toolkit(simples Problem) Java Basics - Anfänger-Themen 8
P Adaptor, Abstract Factory Java Basics - Anfänger-Themen 12
K <class> is not abstract and does not override abstract Java Basics - Anfänger-Themen 5
S Brauche Hilfe bei "abstract" Java Basics - Anfänger-Themen 12
G fenster abstract Java Basics - Anfänger-Themen 18
R abstract class <-> instance Java Basics - Anfänger-Themen 6
G Abstract Class - Abstract Method Java Basics - Anfänger-Themen 4

Ähnliche Java Themen

Neue Themen


Oben