Clase 09a frameworks_ejemplo

  • 186 views
Uploaded on

 

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
186
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
26
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 1FrameworksUn Ejemplo Ilustrado(Arquitectura de Software para Practicantes)Universidad de los AndesDemián GutierrezNoviembre 2012
  • 2. 2EJEMPLO:¡Implementemos unSolitario!Ejemplo de Framework
  • 3. 3Un solitario es un juegoen el que hay:Ejemplo de FrameworkEntendiendo el DominioCartas: Unidadesbásicas que semueven de un lado aotro, bien sea deforma separada o engruposBases: Lugaresdonde poner cartas,aplican reglas sobreque cartas sepueden poner /quitarPilas: Grupos decartas, generalmentesobre una base (o enmovimiento, a modode un grupo decartas). Aplicanreglas sobre quecartas se puedenquitar o añadir de/auna pila
  • 4. 4El objetivo del juego es acomodarlas cartas de cierta forma oeliminar todas las cartas de lasmesa, siguiendo una serie dereglas predefinidas que dicen quecartas se pueden mover de una pilaa otra...Ejemplo de FrameworkEntendiendo el Dominio
  • 5. 5Prácticamente, se pueden definir unconjunto infinito de posibles reglas yjuegos distintos usando el mismo principioEjemplo de FrameworkEntendiendo el DominioSólo acepta una “A”de cualquier colorNOOK
  • 6. 6Ejemplo de FrameworkEntendiendo el DominioUna pila que sólo aceptacartas con valordescendiente y color alternoNONOSI
  • 7. 7Ejemplo de FrameworkEntendiendo el DominioUna pila de la quesólo se puede sacarla carta del tope ogrupos de cartas quelleguen alternando sucolor con valordescendente al topeNOSISI
  • 8. 8Si vamos a programar un juego desolitario hay dos opciones:1) Programar un sólo juego en especifico, conreglas especificas2) Programar una serie de clases (framework)que permitan luego “configurar” las reglasfácilmente para así poder crear cualquier solitarioque se requiera¿Qué opción seleccionaría?¿Por qué?¿Programar un Solitario o un Framework?
  • 9. 9Arquitectura de una Posible ImplementaciónMainFramerepresentan laIU del solitarioEs la clase encargadade cargar las cartasdel disco, en ciertosentido, representa el“mazo de cartas”Utilitarios y clasesbase de SwingUtilitarios en generalObjetos del Solitario, Cartas,Pilas, “Dibujables”, etcPanel en el que se dibujanlas cartas (o que “contiene”el solitario)El código de este ejemplo va adjunto a lastransparencias, son los proyectosCardGames01 y CardGames02
  • 10. 10Arquitectura de una Posible ImplementaciónGamePanel seencarga de dibujar laspilas de cartas (que asu vez dibujan lascartas individuales) asícomo de manejar loseventos del ratónLos eventos del ratón semanejan de forma genéricapor parte de GamePanel,es decir, las reglas de quecartas se pueden quitar deuna pila o poner en otra noestán implementadas enesta claseLas reglas de las pilasestán implementadas encada una de las pilas. Porejemplo borrowCards esinvocado para ver si esposible quitar un grupo decartas de una pila,acceptCards es invocadopara ver si es posibleponer un grupo de cartasen una pila particular. Todala lógica y la verificación seimplementa en estos dósmétodos de las distintaspilasVer diagramas de secuenciade las siguientes láminaspara entender el proceso completo de tomar de una pila y poner en otra
  • 11. 11Arquitectura de una Posible ImplementaciónLo que sucede cuando el usuarioaprieta el ratón (sobre una pila)Si el puntero no estásobre una pilasrcStack es nuloSi no se permite (porreglas) mover lascartas selecionadas,tmpStack es nulo
  • 12. 12Arquitectura de una Posible ImplementaciónLo que sucede cuando el usuario libera el ratón (sobre una pila)Si el ratón no se liberasobre una pila tgtStackserá nuloSi acceptCards retornafalso, quiere decir quela pila por sus “reglas”no aceptó las cartas, yque deben serdevueltas a la pila deorigen
  • 13. 13Arquitectura de una Posible ImplementaciónEs decir, desde el punto de vista de GamePanel, toda lalógica de “si es posible sacar una o más cartas deuna pila” o “si es posible poner una o más cartas enuna pila” está implementada en la clase Stack,específicamente en los métodosborrowCards y acceptCards (respectivamente)¿Cómo podríamos tener pilas que tengan distintoscomportamientos? por ejemplo, ¿Cómo podríamostener una pila que acepte sólo cartas del mismo color yotra que acepte cartas de colores alternados?
  • 14. 14Arquitectura de una Posible ImplementaciónQue tal si se especializa Stack en distintos tipos de pilas,donde cada una de ellas sobrescribe (overrides) el métodoacceptCards() y define reglas particulares para cada tipo depila que se necesite¿Desventajas? ¿Inconvenientes?¿Qué tipo de framework, caja negra o caja blanca?Acepta cartas sólo delmismo colorAcepta cartas decolores intercaladosAcepta cartas sólo devalores descendentesAcepta cartas sólo devalores ascendentes
  • 15. 15Arquitectura de una Posible ImplementaciónEl problema es que esta estrategia puede terminar en unasituación poco deseable, en la que se produzca unaexplosión de clases con funcionalidad redundante, tal comoocurre en el diagrama ...... y eso que no se ha considerado aún la necesidad deespecializar el comportamiento de borrowCardsAcepta cartas sólo devalores descendentes y delmismo colorAcepta cartas sólo devalores ascendentes y delmismo color (¿¿¿Opps, noesta esto repetido???)Acepta cartas sólo devalores ascendentes ydecolores alternados, etc,etc, etc...
  • 16. 16Arquitectura de una Posible Implementación¿Alguna solución al problema de la explosión de clases?
  • 17. 17Arquitectura de una Posible ImplementaciónEn este caso, una pila está compuesta de una serie de“Estrategias” de “prestamo” (BorrowRule) y de “aceptación”(AcceptRule) de cartas que se pueden combinarindependientemente unas de otrasDefine la interfaz deuna “pequeña” claseque establece uncomportamiento de“prestamo” de cartasDefine la interfaz deuna “pequeña” claseque establece uncomportamiento de“aceptación” de cartasLa clase pila estácompuesta por una seriede reglas de “prestamo”y ”aceptación” de cartas
  • 18. 18Arquitectura de una Posible ImplementaciónCada una de lasclases de este colordefinen una regla parapoder “prestar” unacarta o un grupo decartas de la pilaLas clases verdes definen una regla de aceptación, por ejemplo DescendantAcceptRule que sóloacepta cartas con valores consecutivos descendientes, que se pueden encadenar con otras reglas,como SameColorAcceptRule, para obtener una pila que solo acepta cartas descendientesconsecutivas en valor del mismo colorEl método addAcceptRulerecibe una instancia deuna regla y la añade a lalista de reglas a verificar almomento de solicitarle a lapila que “acepte” una cartao un grupo de cartas.El método acceptCardsfunciona de la formatradicional, sólo queejecuta la cadena dereglas añadidas y si todaspasan, entonces acepta lacarta o el grupo de cartas
  • 19. 19Arquitectura de una Posible ImplementaciónEn general, esta es una estrategia completamente cajanegra, porque no es necesario conocer como funciona unaclase particular del framework (Stack en este caso) parapoder heredar y sobrescribir métodos, simplemente basta conimplementar una serie de interfaces y componer la pila deestas “reglas” que son las que hacen el trabajo
  • 20. 20Arquitectura de una Posible ImplementaciónEn este ejemplo (y en los que vimos de patrones de diseño)se ve la importancia de programar en función de interfacesbien definidas, que pueden ser implementadasposteriormente a gusto de los programadores y según lasnecesidades que se tengan
  • 21. 21Gracias¡Gracias!