Frustrations liées à la conception de classes lors du passage de Java à ActionScript

Question

Je travaille principalement en Java, mais j'ai récemment commencé à utiliser ActionScript 3.0 pour un jeu Flash multi-joueurs que j'aide à développer. Le projet n'en est qu'à ses débuts, et je travaille encore sur la structure des classes. Je continue à me heurter à des limites avec le langage ActionScript lorsque j'essaie d'utiliser les nombreuses fonctionnalités de la POO que j'attends de Java.

Par exemple :

• J'ai besoin d'un résumé Character classe. Il n'y a aucune raison pour que Character ne serait jamais instanciée, mais ActionScript ne prend pas en charge les classes abstraites. En conséquence, mon code comporte ce commentaire en haut de page :

Le caractère devrait être une classe abstraite, mais AS ne prend pas en charge les classes abstraites.

NE CRÉEZ PAS D'INSTANCE DE CETTE CLASSE. (N'instanciez que classes qui étendent celle-ci (ex. Player, Zombie))

• En raison de la conception de Flixel (la bibliothèque que nous utilisons), je dois avoir une CharacterGroup avec une classe interne Character de sorte que a CharacterGroup peut également contenir d'autres sprites comme des armes et autres. En Java, j'utiliserais une classe interne. ActionScript ne prend pas en charge les classes internes. Il existe ce qu'on appelle une "classe d'aide", mais les classes d'aide ne sont pas héritées, ce qui les rend inutiles dans ce contexte.

Ma question est la suivante : Est-ce que la capacité d'ActionScript à gérer la conception OOP est simplement moins développée ou est-ce que je trouve ActionScript si frustrant parce que j'essaie de l'écrire comme si c'était Java au lieu de me concentrer sur la façon dont ActionScript a été conçu ?

En d'autres termes, la méthode "correcte" de conception OO est-elle différente en ActionScript et en Java ?

(Note : Je ne demande pas d'avis sur les raisons pour lesquelles ActionScript est meilleur/mauvais que Java. Je demande seulement si je code correctement ou si j'essaie de tirer une trop grande partie de mon expérience de Java).

Gracias.

Answer 1

C'est un peu subjectif, mais personnellement, je dirais que la façon "correcte" de faire de la conception OO dans AS3 est la même que dans Java et oui, AS3 est juste moins développé.

AS2 était très largement basé sur des prototypes, comme JavaScript l'est actuellement, bien que, comme avec JavaScript, vous puissiez toujours le programmer pour qu'il corresponde à un style classique. Puis vint AS3 qui était basé sur une ébauche de l'ECMAScript édition 4. La mise à jour de l'ECMAScript l'a rendu plus classique, proche de Java (JavaScript 2 qui devait être basé sur celui-ci, mais a été abandonné car les membres du comité ont estimé qu'il changeait trop). Ainsi, alors que AS3 est maintenant un langage plus classique de style Java, comme vous l'avez découvert, il est léger en termes de fonctionnalités de langage. De mémoire, il manque des choses comme :

• surcharge des opérateurs
• surcharge des fonctions
• génériques
• classes abstraites
• fonctions en ligne
• les classes internes que vous avez signalées

et probablement beaucoup d'autres choses que d'autres langues ont et dont je ne suis pas au courant. Il est compréhensible qu'il soit ennuyeux de ne pas pouvoir utiliser les fonctionnalités du langage auxquelles on est habitué, mais la plupart du temps, j'ai appris que les choses qui manquent sont des luxes*. Vous pouvez vous en passer, c'est juste que parfois, cela peut rendre votre code un peu plus dangereux et verbeux et c'est juste quelque chose avec lequel vous devez apprendre à vivre.

Il y a quelques moyens de piratage pour essayer d'émuler certaines de ces caractéristiques mais je m'en donne rarement la peine.

*Vous pouvez aussi essayer de regarder la langue Haxe . Le code est compilé en LLVM en bytecode ABC. Le langage Haxe supporte les génériques, les fonctions en ligne, la compilation conditionnelle (et plus encore). Je l'utilise chaque fois que j'écris une bibliothèque.

Answer 2

L'AS3 ne manque pas de fonctionnalités et vous ne pouvez pas la définir comme "moins développée".

Tout d'abord pour votre problème - il existe des moyens de contourner la méthodologie des classes abstraites. Pour votre classe abstraite Caractère - vous pouvez faire en sorte que le développeur utilisateur reçoive une erreur lorsqu'il essaie de l'instancier.

package com.strangemother.database.abstract
{ 

    public class CentralDispatch extends EventDispatcher
    {
        private static var _centralDispatch:CentralDispatch;

        public static function getInstance():CentralDispatch
        {
            if(!_centralDispatch)
                _centralDispatch = new CentralDispatch(SingletonLock);

            return _centralDispatch;

        }

        public function CentralDispatch(lock:Class)
        {
            if(!lock is SingletonLock)
            {
                throw new Error("CentralDispatch is a singleton. Use CentralDispatch.getInstance() to use.");
            }
        }

    }
}

internal class SingletonLock{}

Comme vous pouvez le constater, cette méthode doit être utilisée par la méthode '.getInstance' - mais pour étendre cette méthode, seule cette classe peut créer une nouvelle instance d'elle-même, car c'est la seule classe qui peut voir la classe interne 'SingletonLock{}'. Dans votre cas, vous pouvez supprimer la méthode 'getInstance()' et forcer l'utilisateur à recevoir une instance de cette classe d'une autre manière.

Cela devrait également permettre d'afficher la possibilité de créer des classes internes. Celles-ci ne peuvent être vues par aucune autre classe - seuls ce paquet et la classe mère CentralDispatch peuvent les utiliser.

---

Une autre façon d'utiliser la méthode des fonctions abstraites est de les écrire dans un fichier de type interface

package com.strangemother.database.engines
{
    import com.strangemother.database.Model;
    import com.strangemother.database.ModelSchema;
    import com.strangemother.database.events.ModelEvent;

    public interface IEngine
    {
        /**
         * Reads modelSchema and calls generateModel upon
         * each model found.
         * */
        function generateModelSchema(modelSchema:ModelSchema=null):String

        /**
         * Generate your CREATE syntax model to output to your SQL
         * 
         * If you are extending the framework with your own database
         * engine, you must override this with your own model generation
         * format.
         * */
        function generateModel(model:Model):String

    }
}

alors à tout moment pour l'utiliser, il faut l'implémenter au niveau de la classe

public class SQLite3 extends EngineBase implements IEngine
{

maintenant ma classe SQLite3 doit ont les méthodes définies dans IEngine

---

Je préfère de loin écrire des classes avec des fonctions définies qui sont surchargées lorsqu'elles sont implémentées.

AbstractBase.as

/**
         * connect to the database. This is not usually
         * required as the abstraction layer should
         * automatically connect when required.
         * */
        public function connect(onComplete:Function=null):void
        {

SQLite3 dont l'extension AbstractionBase à un moment donné

overide public function connect(onComplete:Function=null):void

---

Maintenant pour réfuter le commentaire de @Allan sur le fait qu'il soit moins développé (Désolé mec)

Pas de surcharge d'opérateurs - c'est correct mais Java non plus. Cela n'a pas été appliqué pour garantir la lisibilité de AS3.

surcharge de fonctions - Vous ne pouvez pas la taper en dur, mais vous pouvez avoir des function makeTea(...args) Vous avez également des getters/setters.

pour les fonctions en ligne, vous pouvez créer des fonctions anonymes.

var myFunction:Function = Function(name:String):String{ return name + ' - rocks!'; }

Vous avez des classes dynamiques, donc une surcharge au niveau de la classe -

---

Un bon exemple de code réel est Flex Lib - il est open source et vous pouvez lire comment tous ces éléments sont gérés en parcourant le code.