Dégradation des composants Flex - Meilleure pratique

Question

Très souvent, je suis confronté au même problème avec Flex: Lorsque je crée un habillage pour un composant spark ou que je crée un nouveau composant spark à partir d'un autre composant spark, j'ai hérité de propriétés dont je n'ai pas besoin. Par exemple, lorsque je crée un habillage personnalisé pour spark.components.Panel, je n'ai pas besoin de RectangularDropShadow. Au moment de m'en débarrasser, je l'enlève du code MXML et crée une variable publique dans l'AS du même type nommé comme il était dans l'ID du composant supprimé. Je fais ceci pour satisfaire le principe de Liskov pour OOP et cela fonctionne (http://en.wikipedia.org/wiki/Liskov_substitution_principle) mais j'ai des propriétés inutilisées/variables qui n'est pas gentil. Je ne pense pas que ce soit la meilleure façon de le faire.

Bien sûr, il existe une autre approche: Afin de créer un panneau personnalisé sans les fonctionnalités héritées inutiles spark.components.Panel Je dois créer mon propre panneau personnalisé hérité de super classe de spark.components.Panel par exemple. Cette approche implique un travail supplémentaire, mais il s'agit d'une approche OOP directe.

Mais peut-être existe-t-il d'autres techniques spécifiques à Flex que je ne connais pas encore?

Je voudrais savoir comment Flex-gurus gérer ce problème. Toutes vos idées et suggestions sont les bienvenues!

Answer 1

Je ne sais pas si c'est ce que vous cherchez, mais vous pouvez utiliser le Exclude metadata pour indiquer au code qu'il faut ignorer le style ou la propriété.

Il n'est pas rare dans Flex Framework de trouver du code qui exclut une propriété, puis remplace le getter et le setter pour qu'ils ne fassent rien. Cela dans les métadonnées:

[Exclude(name="label", kind="property")] 

Et ce que le code:

override public get function label():String{return null} 
override public set function label(value:String):void { } 

Vous pouvez supprimer des styles en utilisant:

[Exclude(name="RectangularDropShadow", kind="style")] 

Bien sûr, cela affecte tout hinting code. Le code pour implémenter le style sera probablement encore dans votre composant.

Ce dont vous parlez, c'est juste la nature de l'héritage. Pourquoi est-il important pour vous de supprimer ces styles/propriétés du code?

Answer 2

Eh bien, si cela est spécifique à écorcher composants Flex, vous pouvez facilement pas utiliser la classe RectangularDropShadow par extension au lieu ProgrammaticSkin ou votre propre classe ProgrammaticSkin qui implementes les méthodes IProgrammaticSkins.

Quote:

Bien sûr, il y a une autre approche: Pour créer panneau personnalisé sans caractéristiques héritées non nécessaires spark.components.Panel je dois créer mon propre panneau personnalisé hérité de Super classe de spark.components.Panel par exemple.

Pour cela, je pense que vous vous en inquiétez trop. Tout ce qui vous rend plus confortable bien sûr, mais l'une des contraintes de conception architecturale de Flex est de permettre aux développeurs de développer rapidement des RIA sans avoir à se soucier de petites choses embêtantes comme la gestion de la mémoire. Cependant, bravo à vous pour vous inquiéter des fonctionnalités inutiles et des ressources gaspillées, mais je ne pense pas que ce soit nécessaire car ce serait une perte de temps de créer votre propre classe Panel chaque fois que vous avez besoin d'un ensemble de fonctionnalités légèrement différentes. Mais bon, c'est comme si Ma avait toujours dit: "La mémoire libre est une mémoire gâchée!"