Code Behind

Extrae la lógica de Presentación fuera de la vista, poniéndola en una superclase. Esta técnica es probablemente una de las más conocidas en el mundo Flex.

Características del patrón
• La lógica y otros aspectos de desarrollo, están en una superclase ActionScript
• El layout y otros aspectos de diseño, están en una subclase MXML

NOTAS SOBRE EL PATRÓN

Segregación del lenguaje

Ayuda al flujo de trabajo del desarrollador. La división de responsabilidades entre ActionScript y MXML, varía según las implementaciones. Por ejemplo, los Event handler se pueden sacar a clases ActionScript, pero hay quien prefiere que permanezcan en el fichero MXML.

Unit Testing
Parece ser más “testable” que Autonomous View.
Las clases Code-behind tienen referencias a sub-vistas, por lo que para testearlas necesitan mock objects.

¿Porqué extraer una superclase?
Con la excepción del patrón Autonomous View, los otros patrones tienden a separar la lógica de la vista a clases ActionScript. El patrón Code Behind es el único que intenta extraer la lógica en una superclase. Esta técnica se suele usar para mover las funcionalidades compartidas por varias clases, para así no duplicar código.

Separación pobre
Extrayendo hacia una superclase, se obtiene una clase ActionScript que es muy parecida a la que se obtiene si extendemos un componente del Flex framework, como un HBox o Panel. Es difícil ver una separación real en este caso. Como pasa con Autonomous View, los aspectos de layout siguen estando en la vista y no se tiene una clase base común editable.

Acoplamiento
Las dos clases resultantes al aplicar code behind, estarán acopladas. Una herencia es posiblemente la relación más íntima de las asociaciones. En arquitecturas avanzadas, puede ser necesario tener más de una clase de lógica para cada vista, esto no es posible cuando la vista extiende la clase que implementa la lógica.

¿Entonces, MXML es solo para diseñadores?
Hay dos características lógicas de Flex que sólo están disponibles en los MXML:
• Bindings con ‘{}’
• Event handlers declarativos

Podemos pasar sin estas características, pero se echarían de menos.

Aplicación de ejemplo
En este ejemplo vemos la aplicación de este patrón.

Observamos como cada vista hereda de una clase, la cual extiende algún tipo de container. Esto es para que pueda contener otros componentes. En estas superclases se coloca la lógica que necesita la vista, y en la vista ponemos únicamente elementos de vista, valga la redundancia. Un inconveniente que se deriva es que la lógica de la superclase sólo puede ir dirigida a elementos de la vista que hayamos referenciado en la superclase, es decir, la superclase sólo puede aplicar su lógica a objetos declarados en ésta, que se relacionan con los objetos que contiene la vista. Ésto implica que para cada nuevo elemento que pongamos en la vista, si queremos que la superclase pueda tratarlo en su lógica, tendrá que ser declarado dentro de la superclase.

Conclusiones sobre este patrón
Aunque la lógica se extrae de la vista, la clase code-behind resultante está bastante acoplada al Flex framework. Además, teniendo la vista heredando de la clase code-behind, se obtiene una vista acoplada a la lógica.
Supervising Presenter y Presentation Model ofrecen más flexibilidad.