Ergebnis 1 bis 20 von 34

Thema: Indie 2D-Game-Maker (Arbeitstitel: Brickwork)

Hybrid-Darstellung

Vorheriger Beitrag Vorheriger Beitrag   Nächster Beitrag Nächster Beitrag
  1. #1
    Komponenten sind einfache Klassifizierungen von Objekten; Typen sind konkrete Vorlagen.
    Ich würde sicher nicht zustimmen, dass Komponenten und Typen das selbe sind. Wenn man als Vergleich eine Programmiersprache wie Java heranzieht würden Komponenten den Interfaces entsprechen und Typen den Klassen. Das ist zwar eng beeinander, aber nicht wirklich das selbe.

    Was allerdings in meinem Aufbau wirklich (relativ) überflüssig ist sind die Typen.
    Rein theoretisch könnte man Typen aus der Hierarchie entfernen und jedes Objekt würde Komponenten und Scripte enthalten.

    Typen sind aber extra eingefügt um als eine Art Template zu dienen. Sie initialisieren Variablen (was Komponenten nicht können) und binden Scripte ein (auch wenn ein Script ohne ein Objekt keinen Sinn macht).

    Man könnte natürlich die klassische Vererbung von alt bekannten Programmiersprachen einführen und erlauben, dass ein Typ einen anderen Typen erweitert. Das sollte in diesem Fall sogar mit Mehrfach-Vererbung funktionieren.
    Das ganze könnte im Editor aber vielleicht ein wenig unübersichtlich werden und für Anfänger eher verwirrend, aber ich werde mir die Option offen lassen.
    Danke für das Feedback.

  2. #2
    Zitat Zitat von Cornix Beitrag anzeigen
    Man könnte natürlich die klassische Vererbung von alt bekannten Programmiersprachen einführen und erlauben, dass ein Typ einen anderen Typen erweitert. Das sollte in diesem Fall sogar mit Mehrfach-Vererbung funktionieren.
    Du weißt aber hoffentlich auch, was das Problem bei Mehrfachvererbung ist, und wieso dies auch fast keine Programmiersprache unterstützt, oder?
    Das Implementieren von Interfaces ist nur ein Workaround, um so was ähnliches, wie eine Mehrfachvererbung realisieren zu können. Auch wenn man immer wieder Interfaces mit Mehrfachvererbung in Verbindung bringt (besonders in der deutschen Literatur), haben Interfaces primär nichts mit Mehrfachvererbung zu tun. Sie dienen dafür, Klassen klar zu definieren. Angenommen wir möchten Klassen entwickeln, die Daten in unterschiedliche Dateiformate speichert. Eine Klasse speichert die Daten ins XML-Format und eine andere Klasse ins CSV-Format. Mit einem Interface legen wir dann die Methoden fest, die beide Klassen implementieren sollen, damit wir beide Klassen auf die selbe Art und Weise ansprechen können. Klar kann dabei eine Klasse mehrere Interfaces implementieren, aber selbst das hat so seine Tücken. Angenommen wir haben zwei Interfaces, die den selben Methodenamen definieren, aber beide Methoden was anderes machen. In der Klasse selber steht uns aber nur eine einzige Methode zur Verfügung. Um der Sache noch eine Krone aufzusetzen, geht man noch einen kleinen Schritt weiter, und nennt dies das Diamond-Problem.

    Es ist also falsch, ein Java-Beispiel für Mehrfachvererbung zu zeigen, weil Java so was überhaupt nicht kann, und auch kein Konzept dafür vorsieht. Wie gesagt, das Implementieren von Interfaces ist nur ein Workaround, und führt sogar zu Codeverdoppelung, die man aufgrund von Objektorientierung vermeiden möchte. Im Schlimmsten Fall führt diese Art von Mehrfachvererbung sogar zu Inkonsistenzen, wenn man anfängt die Methoden zu ändern. Dann müssen diese Methoden wieder überall geradegebogen werden, was je nach Komplexität schwierig werden kann.

    Wenn ich sowas wie Mehrfachvererbung brauche (was aber bis jetzt noch nie vorgekommen ist), würde ich es wohl so realisieren:

    Code:
    public interface A
    {
        void MethodeA();
    }
    
    public interface B
    {
        void MethodeB();
    }
    
    public class AImpl implements A
    {
        public void MethodeA()
        {
            ...
        }
    }
    
    public class BImpl implements B
    {
        public void MethodeB()
        {
            ...
        }
    }
    
    public class C implements A, B
    {
        private AImpl a = new AImpl();
        private BImpl b = new BImpl(); 
    
        public void MethodeA()
        {
           this.a.MethodeA();
        }
    
        public void MethodeB()
        {
           this.b.MethodeB();
        }
    }
    So kann ich wenigstens sicher sein, dass eine Methodenänderung in AImpl oder BImpl auch in C greift, da C hauptsächlich nur noch aus Wrapper-Methoden besteht. Das Diamond-Problem besteht aber weiterhin.

    Ich bin mal gespannt, wie du diese Probleme lösen willst.

    Edit:
    Wenn man mein Beispiel für eine Mehrfachvererbung nun fortführt, dann kann man für C auch ein Interface bauen. In Java ist es z.B. möglich Interfaces zu erweitern:
    Code:
    public interface C extends A, B
    {
        void MethodeC();
    }
    
    public class CImpl implements C
    {
        private AImpl a = new AImpl();
        private BImpl b = new BImpl(); 
    
        public void MethodeA()
        {
           this.a.MethodeA();
        }
    
        public void MethodeB()
        {
           this.b.MethodeB();
        }
    
        public void MethodeC()
        {
           // tu was
        }
    }
    Wenn du deine Typen und Komponenten so implementierst, wie in meinen Code-Schnipseln, dann wirst du erkennen, dass die Typen und Komponenten das selbe sind. Beide haben ein Interface und eine Klasse, die das Interface implementieren, und du fügst die Klassen mittels Wrapper-Methoden zusammen.

    Geändert von Whiz-zarD (04.02.2014 um 08:46 Uhr)

  3. #3
    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Du weißt aber hoffentlich auch, was das Problem bei Mehrfachvererbung ist, und wieso dies auch fast keine Programmiersprache unterstützt, oder?
    Mehrfachvererbung wird von sehr vielen Programmiersprachen unterstützt und das Problem der Mehrfachvererbung hat in meiner Datenstruktur keine Relevanz.
    Da Objekt-Typen lediglich Attribute besitzen und keine Methoden gibt es auch kein Problem der Mehrfachvererbung.


    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Es ist also falsch, ein Java-Beispiel für Mehrfachvererbung zu zeigen, weil Java so was überhaupt nicht kann, und auch kein Konzept dafür vorsieht. Wie gesagt, das Implementieren von Interfaces ist nur ein Workaround, und führt sogar zu Codeverdoppelung, die man aufgrund von Objektorientierung vermeiden möchte.
    Ich habe nirgends ein Java-Beispiel für Mehrfachvererbung gezeigt, wie kommst du darauf?
    Außerdem glaube ich nicht, dass du Interfaces korrekt verstanden hast, zumindest nicht in dem Sinne wie sie allgemein üblich verstanden werden.
    Interfaces sind genau was ihr Name aussagt, eine Schnittstelle in einem Programm. Wenn du versuchst sie für Mehrfachvererbung zu verwenden, dann machst du etwas falsch.
    Wenn du eine Hierarchie einbauen willst, welche equivalent zur Mehrfachvererbung in Java wäre, dann musst du das Delegations-Pattern verwenden. Aber das driftet jetzt doch sehr stark in den Bereich des Off-Topic.

  4. #4
    Zitat Zitat von Cornix Beitrag anzeigen
    Ich habe nirgends ein Java-Beispiel für Mehrfachvererbung gezeigt, wie kommst du darauf?
    http://www.multimediaxis.de/group.ph...576&do=discuss

    Zitat Zitat von Cornix Beitrag anzeigen
    Interfaces sind genau was ihr Name aussagt, eine Schnittstelle in einem Programm. Wenn du versuchst sie für Mehrfachvererbung zu verwenden, dann machst du etwas falsch.
    Und wieso benutzt du sie für Mehrfachvererbung?

  5. #5
    Wo ist hier ein Beispiel für Mehrfachvererbung? Ich sehe keines, und das Wort taucht auch nicht auf der Seite auf.


    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Und wieso benutzt du sie für Mehrfachvererbung?
    Das tue ich auch nicht. Ich benutze keine Interfaces, ich benutze Objekt-Typ-Komponenten. Ich sagte lediglich, dass man ein equivalentes Java-Programm schreiben könnte, welches gleich funktioniert, falls man Komponenten mit Interfaces gleichsetzt. Außerdem werden sie dort auch nicht zur Mehrfachvererbung verwendet sondern als implizite Attribute.

  6. #6
    Ich verstehe die einzelnen Komponenten bisher auch weniger als Klassen denn als Vorlagen, die den Zweck haben, dass der Entwickler den Code für ein bestimmtes Objekt oder Script nicht immer komplett neu schreiben muss. Oder hab ich das falsch verstanden?

  7. #7
    Zitat Zitat von Kelven Beitrag anzeigen
    Ich verstehe die einzelnen Komponenten bisher auch weniger als Klassen denn als Vorlagen, die den Zweck haben, dass der Entwickler den Code für ein bestimmtes Objekt oder Script nicht immer komplett neu schreiben muss. Oder hab ich das falsch verstanden?
    Naja, nur irgendwas muss mit diesen Daten später geschehen, und da würde es sich anbieten, aus diesen Daten Klassen zu generieren, die dann in Bytecode übersetzt werden.
    Oder wie soll das hinterher von statten gehen?

  8. #8
    Das kann ich dir nicht sagen, ich hab noch nie einen Compiler gebaut.

  9. #9
    Compiler? Ich dachte es geht um Java?

  10. #10
    Der Übersetzer in Bytecode nennt sich auch Compiler
    http://de.wikipedia.org/wiki/Java_Development_Kit

  11. #11
    Zitat Zitat von Kelven Beitrag anzeigen
    Ich verstehe die einzelnen Komponenten bisher auch weniger als Klassen denn als Vorlagen, die den Zweck haben, dass der Entwickler den Code für ein bestimmtes Objekt oder Script nicht immer komplett neu schreiben muss. Oder hab ich das falsch verstanden?
    Das ist so schon richtig. Komponenten sind lediglich gewisse Vorlagen zur Datenhaltung.

    Zitat Zitat von Whiz-zarD Beitrag anzeigen
    Naja, nur irgendwas muss mit diesen Daten später geschehen, und da würde es sich anbieten, aus diesen Daten Klassen zu generieren, die dann in Bytecode übersetzt werden.
    Oder wie soll das hinterher von statten gehen?
    Das bietet sich eher nicht an. Für diesen sehr limitierten Nutzen wäre es zwar auch möglich, aber aus meiner Sicht nicht sinnvoll soetwas zu tun. Nicht nur wegen dem überproportionalen Overhead, sondern vor allem auch wegen gängigen Design Paradigmen.
    Die Daten werden auf andere Art und Weise verarbeitet.

    Zitat Zitat von tuxtuxtux Beitrag anzeigen
    Compiler? Ich dachte es geht um Java?
    Java verwendet einen Compiler. Meistens sogar zwei: Einen um den Java-Code zu Java-Byte-Code zu kompillieren, und dann in der JVM einen Just-In-Time Compiler um den Java-Byte-Code in Maschinen-Code zu kompillieren. Der zweite ist zwar gängig aber optional da der Java-Byte-Code auch interpretiert werden kann.

  12. #12
    Zu dem ganzen Java-Kram will ich mich jetzt eigentlich nicht äußern, aber ich will dir einfach viel Erfolg bei der ganzen Sachen wünschen. So ein "Game Maker" ist bei weitem nichts leichtes und Bedarf viel Überlegung und Refactoring imho. Schau dir auch andere Engines an, was die machen (Unity3D, Contruct, Game Maker etc). Ist immer gut wenn du dir praktisch Sachen abgucken kannst. Das Rad neu zu erfinden auch sehr schwer. Und da wir ja selber unsere eigene Engine gemacht haben und verwenden, hier ein kleiner Tipp: "Schau dir ruhig einige Sachen vom Maker ab". Der Maker hat einige tolle Sachen gemacht, die du eben beim Spiele entwickeln immer mal brauchst (Events with multiple pages, Storage of Values via Key/Value etc.).

    Bin gespannt wie weit sich das entwickelt

  13. #13
    Ich hab mir jetzt nicht den ganzen Thread genau durchgelesen, aber um das problem der mehrfachvererbung zu umgehen könnte man auch ein Entity-Component-System benützen.

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •