2013-06-05 3 views
0

je définis 3 interfaces dans mon projet de flex, "B", "C" et "D". L'interface "D" étend l'interface "B", et l'interface "C" est un consommateur de l'instance de type "B". Après cela, j'ai défini 2 modules, M1 et M2. M1 implémente l'interface "D" et M2 implémente l'interface "C". M2 a une fonction publique comme suit.communication entre les modules de flexion par des interfaces

/* in the "M2" module */ 
// the stub is declared in the "C" interface. 
public function consume(b:B):void{ 
    if(b is D){     // line 1: type determination 
     // do something on the D interface 
    } 
} 

Et puis je définis 2 chargeurs module (MLD1 & MLD2) pour charger M1 et M2 (en définissant l'URL) dans l'application principale. Et après avoir chargé M1 et M2, j'ai essayé de fournir M1 pour M2 via la fonction "C.consume (B): void" implémentée dans le module M2. Les codes sont comme suit.

/* in the "main" application */ 
var m1:B = mld1.child as B;  // line 2: cast type to B 
var m2:C = mld2.child as C; 
m2.consume(m1);     // line 3: provide m1 instance for m2 

Cependant, lorsqu'il appelle la M2.consume (B): fonction vide dans la ligne 3, le « si » la détermination de la consommation fonction (ligne 1) toujours échouer et le corps du « si » la structure sera toujours ignorée. Mais si j'ajoute la ligne de détermination de type comme indiqué dans la ligne 1 dans le module "M2" à l'application principale avant la ligne 3, alors la détermination de type dans la ligne 1 sera réussie. C'est-à-dire les codes que ce qui suit dans l'application principale permettra de transmettre la détermination du type dans la ligne 1.

/* in the "main" application: make type determination be line 3 */ 
var m1:B = mld1.child as B;  // line 2: cast type to B 
if(m1 is D)      // just make a plain determination. nothing else. 
    ;        
var m2:C = mld2.child as C; 
m2.consume(m1);     // line 3: provide m1 instance for m2 

ou si je fais un type jeté directement au type D, il sera également atteindre la même résultat.

/* in the "main" application: make type cast before line 3 */ 
var m1:B = mld1.child as D;  // line 2: after modified, cast type to D. 
var m2:C = mld2.child as C; 
m2.consume(m1);     // line 3: provide m1 instance for m2 

Je me demande pourquoi la détermination de la ligne 1 sera couronnée de succès que si je l'ai mentionné le type « D » dans l'application principale. La détermination du type ou le type cast dans l'application principale fera-t-elle une différence sur l'objet cible? Et que dois-je faire, si je souhaite l'application principale d'être conscients de l'interface « B » et son interface à la consommation (l'interface « C »), de sorte que l'application peut prendre en charge toutes les interfaces sous et classes de la « B » et "C" interface.

Merci!

+0

Rien de personnel, mais mon esprit simple est dérouté par cette soupe à l'alphabet :) Je pense que votre explication serait plus claire si vous montriez les noms de variables qui avaient un sens. Va lui donner une autre lecture ... –

+0

@Sunil D. Merci pour vos conseils. J'apprécie beaucoup. En fait, j'ai essayé de les nommer d'une manière méchante, "B" pour l'interface de base, "C" pour l'interface du consommateur et "D" pour l'interface dérivée. Ils prennent juste la première lettre comme identification. Eh bien, peut-être que je n'ai pas précisé cela clairement. – xnslong

Répondre

0

Il est difficile de suivre tout ce que vous avez écrit, donc peut-être je raté quelque chose, mais si vous n'importez pas D dans l'application principale, il ne sera pas compilé dans le fichier SWF résultant. Voilà pourquoi l'application principale ne sera pas au courant de D.

+0

Merci pour votre réponse. En fait, je m'attends à ce que l'application principale ne soit pas au courant de D, et que les 2 modules chargés par l'application principale en soient conscients. Ce que l'application principale prend soin est à ce sujet, il devrait obtenir un objet de type B et un consommateur de type C qui peut consommer l'objet de type B, et il remettra l'objet B au consommateur de type C avec la fonction C.consume (B) . Comme nous le savons, nous pouvons avoir de nombreuses implémentations pour une interface. L'application principale ne se soucie pas de savoir si l'objet de type B est également une instance de type D ou non. Qui devrait s'en soucier est les modules concrets. – xnslong

+0

La limite de longueur! Eh bien, je souhaite que l'application principale soit une application générale pour toutes les implémentations de toute instance B et de toute instance C. Si seulement j'ai chargé 2 modules (implémentés respectivement l'interface B & C), et que je définis la relation avec la fonction consommer, alors ils pourront fonctionner correctement. Ainsi, l'application principale ne doit pas mentionner l'interface D et les implémentations concrètes M1 et M2, et bien sûr, elles doivent être compilées dans le fichier SWF résultant de l'application principale.Sinon, l'application principale ne sera pas aussi générale que prévu. – xnslong

Questions connexes