Resumen-Examen D1 PDF Diseño de Aplicaciones 1

lOMoARcPSD|44282546 Resumen-Examen D1 Diseño de aplicaciones 1 (Universidad ORT Uruguay) Escanea para abrir en Studocu Studocu no está patrocinado ni avalado por ningún colegio o universidad. Descargado por Thomas Mcculloch ([email protected]...

lOMoARcPSD|44282546 Resumen-Examen D1 Diseño de aplicaciones 1 (Universidad ORT Uruguay) Escanea para abrir en Studocu Studocu no está patrocinado ni avalado por ningún colegio o universidad. Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Resumen Examen Diseño 1 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Tabla de contenido Conceptos POO...........................................................................................................................4 Clase y Objeto - Identidad, Comportamiento y Estado.................................................................4 UML - Paquetes, Clases, Interacción...........................................................................................5 Relaciones entre clases...............................................................................................................7 Asociación................................................................................................................................7 Navegación de las asociaciones..............................................................................................7 Agregación y Composición.....................................................................................................10 Dependencia..........................................................................................................................11 Clases de asociación..............................................................................................................12 Roles......................................................................................................................................12 Constraint...............................................................................................................................12 Stereotypes............................................................................................................................12 Notas......................................................................................................................................12 Clean Code................................................................................................................................12 Selección de nombres............................................................................................................12 Reglas....................................................................................................................................12 Funciones...............................................................................................................................13 Formateo................................................................................................................................14 Clases....................................................................................................................................16 Emergencia............................................................................................................................16 GRASP.......................................................................................................................................17 Experto................................................................................................................................17 Creador...............................................................................................................................17 Controlador.........................................................................................................................17 Bajo Acoplamiento..............................................................................................................17 Alta Cohesión......................................................................................................................17 Fabricación Pura.................................................................................................................17 Indirección...........................................................................................................................18 Polimorfismo.......................................................................................................................18 Ley de Demeter...................................................................................................................18 2 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Refactoring.................................................................................................................................18 Motivos más frecuentes para su uso:..................................................................................18 Beneficios............................................................................................................................18 Potenciales problemas........................................................................................................19 Relación con testing............................................................................................................19 En qué casos aplicar refactoring.........................................................................................19 Técnicas de refactoreo........................................................................................................20 Patrones de Diseño....................................................................................................................20 Singleton................................................................................................................................21 Builder....................................................................................................................................21 Template Method...................................................................................................................23 Strategy..................................................................................................................................23 Fachada.................................................................................................................................24 Conceptos y principios de diseño SOLID...................................................................................24 Responsabilidad única...........................................................................................................25 Principio de abierto-cerrado...................................................................................................25 Liskov.....................................................................................................................................25 Separación de la interfaz........................................................................................................25 Principio de dependencias acíclicas.......................................................................................25 3 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Conceptos POO El Diseño Orientado a los Objetos (DOO) crea una representación del problema del mundo real y la hace corresponder con el ámbito de la solución, que es el software. Todos los métodos de diseño intentan desarrollar software basándose en: Abstracción: Simplificación de la realidad. Si hago una mala abstracción tengo malas clases. Information hiding: Un tipo o una clase debería tener la menor visibilidad posible. Es el proceso de ocultar todos los secretos del objeto que no contribuyen a sus características esenciales. Cada objeto está aislado del exterior y cada tipo de objeto expone una interfaz a otros objetos que específica cómo deben actuar. Hace referencia a que los atributos internos a un objeto no pueden ser modificados ni obtenidos sin pasar por métodos públicos. Modularización: Se basa en reducir la complejidad para poder resolver el problema. Propiedad que permite subdividir una aplicación en partes más pequeñas llamadas módulos, cada una de las cuales debe ser tan independiente como sea posible de la aplicación en sí y de las restantes partes. Encapsulamiento: Consiste en unir en la clase las características y el comportamiento. Es reunir a todos los elementos que pueden identificarse con una misma entidad. Aumenta la cohesión. Cohesión: Es una medida de cuan fuertemente están relacionadas las responsabilidades de una clase. Debe ser alta. Una clase debería de tener una sola razón por la cual cambiar, un solo eje de cambio. Acoplamiento: Es una medida de cuan fuertemente está relacionada una clase o paquete con otras clases o paquetes. Hay dos tipos de acoplamiento, de interfaz o de implementación. El acoplamiento debe ser bajo (se deben evitar relaciones o dependencias innecesarias) y de interfaz. El DOO (diseño orientado a objetos) proporciona un mecanismo que permite al diseñador consigue estas características sin dificultad. El Análisis Orientado a Objetos, el Diseño Orientado a Objetos y la Programación Orientada a Objetos comprenden un conjunto de actividades de la Ingeniería del Software para la construcción de un sistema basado en objetos. Clase y Objeto - Identidad, Comportamiento y Estado Clase: Define un tipo de objetos. Es una especificación genérica para objetos similares. Se compone de atributos y métodos. Los atributos definen información que "almacenan" los objetos pertenecientes a la clase. Los métodos definen operaciones que se pueden utilizar para manipular los objetos pertenecientes a la clase. Es un témplate para crear objetos. Métodos de instancia: métodos que dependen del objeto concreto, por ejemplo getEdad(). 4 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Métodos de clase: son métodos que no dependen del objeto, se llaman sobre la clase. Por ejemplo Console.WriteLine(). No preciso tener objetos creados para llamarlos. EN UML SE SUBRAYAN. Atributos de clase: Son atributos que no cambian por más que se instancien objetos. Objeto: Desde el punto de vista del análisis y el diseño es cualquier entidad tangible o visible del programa, cualquier entidad que se pueda conceptualizar, una entidad receptora de acciones. UN OBJETO ES UNA ENTIDAD IDENTIFICABLE (IDENTIDAD), CAPAZ DE ALMACENAR INFORMACION (ESTADO), Y QUE OFRECE UN CONJUNTO DE OPERACIONES (COMPORTAMIENTO) QUE NOS PERMITEN EXAMINAR Y MODIFICAR SU INFORMACION. El estado de un objeto es el valor del objeto en un momento dado. La identidad es un atributo que diferencia un objeto de otro. No se puede utilizar un atributo que tenga sentido a nivel de dominio para identificar un objeto. La comparación de identidad no es lo mismo que la comparación de igualdad. La igualdad es definida por el desarrollador. Por ejemplo, con la cedula de identidad si puedo comparar igualdad, pero no identidad. El comportamiento queda definido por cómo responde un objeto a un método dependiendo de su estado. UML - Paquetes, Clases, Interacción Package/Namespace: Son elementos de la notación que permiten particionar lógicamente al sistema. Son agrupaciones lógicas de elementos fuertemente relacionaos pero con poco acoplamiento con elementos de otros paquetes. Dentro de un paquete de se pueden agrupar clases, paquetes, colaboraciones y/o casos de uso. La idea de un paquete es que podamos organizar nuestros tipos. Un buen diseño implica que las cosas dentro del paquete están fuertemente relacionadas entre sí. El concepto de paquete no tiene nada que ver con cómo se implementa en disco. En.NET el concepto de paquete se mapea con el namespace. En UML los paquetes se ven así El concepto de paquete facilita la reusabilidad, siempre y cuando las particiones tengan una granularidad coherente. Un paquete puede exportar elementos públicos que contiene a otros paquetes que lo importan, lo que implica que existen asociaciones de algún tipo entre los elementos de cada paquete. En C# la dependencia se implementa con using. 5 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Diagramas de interacción Describen la forma en que los objetos colaborar para lograr algún comportamiento. Se utilizan para:  Especificar casos de uso  Especificar interacción entre métodos UML cuenta con dos tipos de diagramas de interacción:  Diagramas de secuencia  Diagramas de colaboración Diagramas de secuencia vs. colaboración  Ambos expresan lo mismo de distintas formas.  Los diagramas de colaboración son más fáciles para conceptualizar el diseño inicial. Muestran la estructura del sistema.  Los de secuencia muestran mejor el orden del tiempo 6 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Relaciones entre clases Son asociaciones lógicas entre clases. Las formas básicas son la asociación y la dependencia. Asociación Una asociación es una relación estructural que describe una conexión entre objetos. Gráficamente se muestra como una línea continua que une las clases relacionadas entre sí. Navegación de las asociaciones Gráficamente, cuando una asociación es unidireccional, la línea termina en una punta de flecha que indica el sentido de la asociación. 7 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Multiplicidad de las asociaciones La multiplicidad de una asociación determina cuantos objetos de cada tipo intervienen en la relación. El numero de instancias de una clase que se relacionan con UNA instancia de la otra 8 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 clase. Cada asociación tiene dos multiplicidades, una para cada extremo de la relación. Para especificar la multiplicidad de una asociación hay que indicar la multiplicidad mínima y máxima. Relaciones involutivas 9 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Cuando la misma clase aparece en los dos extremos de la asociación. Agregación y Composición Casos particulares de asociaciones, relación entre un todo y sus partes. Gráficamente, se muestran como asociaciones con un rombo en uno de los extremos. Agregación Las partes pueden formar parte de distintos agregados. Representa una relación de compuesto-componente. Es el concepto de "está formado por". Es la típica relación de todo y sus partes. El componente tiene sentido independientemente del compuesto. 10 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Composición Agregación disjunta y estricta: las partes solo existen asociadas al compuesto (solo se accede a ellas a través del compuesto). Es una agregación que implica relación de vida, es decir, sin el compuesto los componentes mueren. El componente no tiene sentido sin el compuesto. Dependencia Relación (más débil que una asociación) que muestra la relación entre un cliente y el proveedor de un servicio usado por el cliente. - Cliente es el objeto que solicita un servicio. - Servidor es el objeto que provee el servicio solicitado. Gráficamente, la dependencia se muestra como una línea discontinua con una punta de flecha que apunta del cliente al proveedor. 11 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Clases de asociación FALTA Roles En cada extremo de la relacion debe especificarse un nombre de rol que muestra como una clase ve a la opuesta. Constraint Es la especificacion de alguna condicion que se debe cumplir para que el modelo sea correcto. Stereotypes Permite especificar una meta-clasificación de elementos del modelo. Son útiles para extender la notación. Es aplicable a todos los elementos básicos de la notación. Notas Sirven para agregar más información. No es bueno abusar de las mismas. Clean Code El código debe ser fácil de leer, de cambiar y de probar tiene que ser mantenible. Selección de nombres Usar nombres de variables que transmitan lo que queremos decir, el nombre debe revelar la intención, y deben ser cohesivos entre sí para que sea fácil de leer. No deben ser nombres que se aten a la implementación (Ej; listaProductos, es mejor usar sólo productos). “Un buen nombre da mucha más información que cualquier otra cosa. Para conseguir buenos nombres hay que usar nombres descriptivos y claros. Deben ser legibles y evitar codificaciones complejas.” C. Martin Reglas  Relevar la intención  Evitar la desinformación (deben se fáciles de buscar y encontrar)  Hacer distinciones importantes (Ej; getCuentaActiva, getCuentaActivaInfo, como se cual usar? Los nombres deben distinguirse)  Los números “mágicos” deben evitarse. Los reemplazo por variables o constantes con nombres que expliquen lo que significan.  Evitar encoding. 12 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Nombres de clases  NO deben ser un verbo  No usar palabras que no sean significativas ej; procesador, datos, etc. Nombres de métodos  Siempre deberían ser (o contener) un verbo.  Nomenclatura estándar ; get, set, is (conocer idioma del lenguaje)  En caso de sobrecarga de constructores, usar factory methods con nombres que describan lo que hacen (se debe entender la diferencia entre constructores)  Debemos ser consistentes, no podemos tener dos métodos, ObteberDatos y LeerDatos  Usar nombres que tengan que ver con el dominio. El código lo van a leer desarrolladores, podemos usar términos como stack job, etc pero cuando no puedo, debo usar términos del dominio. Funciones Las funciones deben tener una sola responsabilidad.  Toda la función debe tener el mismo nivel de abstracción  Deben ser pequeñas  Deben hacer una sola cosa  Leer el código “From top to bottom”. Cada función debe ser seguida por las del siguiente nivel de abstracción (step-down rule). Tengo que poder leer toda la función en el mismo nivel  Evitar los switch (por definición hacen más de una cosa)  Número ideal de parámetros por función entre 0 y 2, si tenemos 3 o más ya no es bueno (es probable que este haciendo más de una cosa).  Evitar pasar booleanos por parámetro. Capítulo 4 - COMENTARIOS Los comentarios no pueden maquillar el mal código. La necesidad de comentarios para aclarar algo es síntoma de que hay código mal escrito que debería ser rediseñado. Es preferible expresarse mediante el propio código. Hay situaciones en las que los comentarios son apropiados, como cuando tratan de:  Aspectos legales del código.  Advertir de consecuencias.  Comentarios TODO.  Remarcar la importancia de algo.  Javadocs en APIs públicas. Sin embargo, en el resto de los casos pueden llevar a confusión y deberían ser evitados. 13 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Formateo El formateo afecta directamente a la legibilidad del código. El código se lee de arriba abajo y de izquierda a derecha. Los espacios verticales y horizontales permiten separar ideas y conceptos distintos. Se debe mantener un estilo uniforme, y para ello se debe consensuar con todo el equipo las reglas de formateo. Las reglas elegidas no son tan importantes como el hecho de que todo el mundo se atenga a ellas. Objetos y Estructura de datos No todo se puede solucionar usando sólo objetos o sólo estructuras de datos. Hay que aprender a diferenciar en qué situaciones son más convenientes unos u otros. Los objetos esconden sus datos y exponen funciones que permiten manipularlos, mientras que las estructuras de datos exponen datos pero no tiene funciones que operen sobre ellos. Manejo de Errores El código de manejo de errores oculta la verdadera funcionalidad del código. Hay que mantenerlo lo más separado posible de la lógica de negocio para no dificultar la comprensión de ésta última. Para no complicar el manejo de errores hay que escribir los bloques try-catch-finally en primer lugar permite identificar los puntos del programa en los cuáles se puede producir una excepción. Se deben usar excepciones en lugar de códigos de retorno. Las excepciones deben proporcionar suficiente información sobre el error y el momento en que se ha producido. Además, las excepciones no comprobadas son menos invasivas a nivel de código. También se debe evitar pasar null como parámetro de una llamada a un método o devolverlo como valor de retorno. Esto introduce complejidad adicional debido a las comprobaciones necesarias. Fronteras Los sistemas dependen de paquetes de terceros o de componentes desarrollados por otros equipos. Hay que definir de forma clara la frontera entre el código y el exterior para poder acomodar de forma sencilla los futuros cambios, minimizando las partes de nuestro código que dependan de elementos externos. Los tests ayudan a experimentar con el código externo viendo cómo puede cubrir nuestras necesidades. También permiten comprobar que las nuevas versiones de la librería siguen cumpliendo con nuestras necesidades. Encapsular el conocimiento adquirido a través de los tests en un interfaz entre nuestro sistema y el código de terceros permite localizar en un único punto las modificaciones debidas a posibles cambios en código que está fuera de nuestro control. Tests Unitarios En TDD los tests se deben escribir en primer lugar. Las 3 reglas de TDD son:  No se debe escribir código de producción hasat que no se tenga un test unitario que falle.  No se debe escribir más de un test unitario que lo necesario para que éste falle. 14 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546  No se debe escribir más código de producción que el necesario para que pase un tests unitario que fallaba. Se debe dar la misma importancia al código de test que al de producción. Los tests permiten que el código de producción se pueda modificar sin temor a introducir nuevos errores, asegurando su mantenibilidad. El número de assert por cada test debe ser lo más bajo posible. Se debe testear un único concepto en cada test, lo que permite ir aclarando los distintos conceptos progresivamente, mejorando el conocimiento sobre el código. Las reglas FIRST sobre el código de test son:  Fast: Se deben ejecutar rápido y muy a menudo.  Independent: Las condiciones de un test no deben depender de un test anterior.  Repeteable: Se deben poder ejecutar en cualquier entorno.  Self-Validating: El propio test debe decir si se cumple o no, no debe hacer falta realizar comprobaciones posteriores al test.  Timely: Los tests se deben escribir en el momento adecuado, que es justo ante de escribir el código de producción, lo que permite escribir código fácilmente testeable. TDD asegura que todo lo que programa cumple con el ESRE (no programo ni de más ni de menos). Ideal de pruebas:  Validar los nulls  String vacíos  Una colección vacía (vacía distinto de NULL), tiene un solo elemento, máxima xantidad de elementos, elementos repetidos  Búsquedas; cuando no encuentro, cuando encuentro un único elemento, cuando encuentro más de un elemento. Metodología:  Escribo un test que verifique un requerimiento, este test no va a compilar.  Voy a escribir EL MINIMO CODIGO POSIBLE para que el test compile.  Corro el test y falla.  Empiezo a cambiar el código hasta que la prueba pasa - La prueba no anda Red -Escribo lo necesario para que la prueba Refactoring Green se pase 15 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 -Refactoreo el código escrito para que la prueba pase. Puedo hacer que la prueba falle Clases Las clases se deben organizar situando en primer lugar las constantes públicas, después las variables estáticas privadas, variables de instancia privadas y, a continuación, los métodos. Los métodos privados se encuentran junto a los métodos públicos que los usan. Se debe mantener la encapsulación de las clases. Las clases deben ser pequeñas y con un número reducido de responsabilidades. Se consigue una alta cohesión si todos los métodos de una clase hacen uso de todas sus variables privadas. Las nuevas funcionalidades se deben de introducir extendiendo el sistema, no modificando el código existente. Las clases concretas contienen detalles de implementación y las clases abstractas expresan conceptos. La dependencia en clases concretas es un riesgo en caso de cambio. Según el principio de inversión de dependencia las clases deben depender de abstracciones. Emergencia Las siguientes 4 reglas dadas por Kent Beck permiten crear buenos diseños según se trabaja en ellos, conocer nuestro sistema y aplicar buenos principios de diseño:  Ejecutar todos los tests: Los tests verifican que el sistema se comporta según lo esperado. Al construir un sistema testeable se intenta que las clases sean simples y tengan un único propósito, y se trata de reducir el acoplamiento.  Eliminar la duplicación: La duplicación implica trabajo adicional, más riesgo y mayor complejidad.  Expresar la intención del programador: Usar un código lo más expresivo posible facilita el mantenimiento. Se deben escoger buenos nombres, funciones y clases pequeñas y tests bien escritos.  Minimizar el número de clases y métodos: Siguiendo las recomendaciones anteriores uno se puede exceder creando demasiadas clases pequeñas. Hay que tener cuidado y mantener un número reducido de clases. Durante la refactorización de puede aplicar todo nuestro conocimiento para mejorar el diseño: aumentar la cohesión, reducir el acoplamiento, separar responsabilidades, reducir funciones y clase, escoger nombres mejores, etc. Se dedicar tiempo a estas tareas después hacer que el software funcione. No se debe pasar a 16 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 la siguiente tarea sin repasar lo hecho. Es imposible conseguir un código limpio a la primera, hay que repasarlo una y otra vez para conseguir mejorarlo progresivamente. GRASP En diseño orientado a objetos, GRASP son patrones generales de software para asignación de responsabilidades. Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software. Acrónimo de "GRASP: General Responsibility Assignment Software Patterns)". Experto Problema: Cómo asignar responsabilidades? Solución: Asignar una responsabilidad al experto de la información; la clase que cuenta con la información necesaria para cumplir con la responsabilidad. Creador Problema: Quién es el encargado de crear una nueva instancia de la clase? Solución: Asignarle a la clase B la responsabilidad de crear una instancia de la clase A en uno de los siguientes casos; B agrega/ contiene/ registra los objetos A, o que B sea experto. Controlador Problema; Quién atiende un evento del sistema? Solución: Al sistema, empresa u organización global (controlador de fachada) Normalmente un controlador debería delegar a otros objetos el trabajo que ha de realizarse. Bajo Acoplamiento Problema: Cómo dar soporte a una escasa dependencia y a un aumento de la reutilización? Solución: Asignar una responsabilidad para mantener bajo el acoplamiento Alta Cohesión Problema: Como mantener la complejidad dentro de los límites manejables? Solución: Asignar una responsabilidad de modo que la cohesión siga siendo alta. Fabricación Pura Asignar un conjunto altamente cohesivo de responsabilidades a una clase artificial (es decir que no representa nada en el dominio del problema) de forma de dar soporte a la alta cohesión y el bajo acoplamiento. 17 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Indirección El patrón de indirección nos aporta mejorar el bajo acoplamiento entre dos clases asignando la responsabilidad de la mediación entre ellos a un tercer elemento (clase) intermedio Problema: Dónde asignar responsabilidades para evitar/reducir el acoplamiento directo entre elementos y mejorar la reutilización? Solución: Asigne la responsabilidad a un objeto que medie entre los elementos. Polimorfismo Siempre que se tenga que llevar a cabo una responsabilidad que dependa del tipo, se tiene que hacer uso del polimorfismo, cuando las alternativas o comportamientos relacionados varían según el tipo (clase), asigne la responsabilidad para el comportamiento- utilizando operaciones polimórficas- a los tipos para los que varía el comportamiento. Asigna el mismo nombre a servicios en diferentes objetos. Ley de Demeter Conocido también como “No hables con extraños..”. Se debe buscar asignar las responsabilidades de forma tal de evitar conocer la estructura interna de objetos indirectos. Refactoring Consiste en modificar la estructura interna del sw para mejorar su desempeño y hacerlo más modificable sin impactar la correctitud y el comportamiento del mismo. Actividad diferente de agregar o modificar funcionalidad (Ej. Cambiar código, no para cambiar funcionalidad sino para cambiar aspectos no funcionales como la mantenibilidad). Altera la estructura interna del sw sin modificar so comportamiento externo. Es un cambio hecho a la estructura interna para hacerlo más fácil de entender y más “barato” para modificarlo sin que cambie su comportamiento externo. Su objetivo es hacer que el código sea más fácil de leer y mantener. Motivos más frecuentes para su uso:  Prototipos que no se desechan  Distintos niveles de experiencia de los diseñadores  Presiones de tiempo Beneficios  Mejorar el diseño  Facilita el entendimiento del software  Disminuye el esfuerzo de programación debido a la mejora del diseño 18 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Potenciales problemas  Algunos refactoreos implican cambios en la interfaz de la clase  Algunas decisiones de diseño dificultan la reestructura  Hay veces que es mejor re escribir el código en lugar de refactorearlo. Relación con testing La utilización de Restructura (o refactoring) requiere contar con casos de prueba unitarios que puedan utilizarse luego de cada reestructuración. Es recomendable escribir código auto “testeable” en que cada clase cuenta con sus casos de prueba. En qué casos aplicar refactoring Código duplicado:  Métodos con código común  Código igual o similar en clases hermanas  Código igual o similar en clases distintas  Código en la clase equivocada Métodos extensos:  Métodos muy largos  Métodos con muchas variables temporarias  Métodos con código comentado 19 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Clases Grandes:  Con muchas variables de instancias poco relacionadas entre sí  Con variables de instancia que se utilizan poco  Clases con mucho código Clases intermediarias:  Clases que delegan demasiado Técnicas de refactoreo Extract Method: Si hay un fragmento de código que puede agruparse, agruparlo en un método cuyo nombre explique lo que hace. Encapsulate field: Si hay un campo público, hacerlo provado y proveer get y set. Move Method: Un método es usado o será usuado más por otra clase que aquella donde está. Mover el método a esa clase y dejar el método viejo en la otra clase en forma de delegación, o borrarlo. Patrones de Diseño Cada patrón describe un problema que se repie una y otra vez en nuestro ambiente y describe la solución para ese problema de forma que esta solución se pueda utilizar un millón de veces sin utilizarse dos veces de la misma forma. Estas decisiones de diseño sirvieron a otros diseñadores. Generar un nuevo vocabulario de diseño. Clasificación:  Creacionales: creación de objetos  Estructurales: composición de clases  Comportamiento: interacción de objetos 20 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Singleton Patrón del tipo creacional (detalle, rompe con el principio de responsabilidad única). Consiste en garantizar que una clase tenga solo una instancia y proporcionar un punto de acceso global a ella. Builder Patrón del tipo creacional. Como Patrón de diseño, el patrón builder (Constructor) es usado para permitir la creación de una variedad de objetos complejos desde un objeto fuente (Producto), el objeto fuente se compone de una variedad de partes que contribuyen individualmente a la creación de cada objeto complejo a través de un conjunto de llamadas a interfaces comunes de la clase Abstract Builder. El patrón builder es creacional. A menudo, el patrón builder construye el patrón Composite, un patrón estructural. Intención: Abstrae el proceso de creación de un objeto complejo, centralizando dicho proceso en un único punto, de tal forma que el mismo proceso de construcción pueda crear representaciones diferentes. 21 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546  Builder: interfaz abstracta para crear productos.  Concrete Builder: implementación del Builder, construye y reúne las partes necesarias para construir los productos.  Director: construye un objeto usando el patrón Builder.  Producto: El objeto complejo bajo construcción. Ventajas:  Reduce el acoplamiento.  Permite variar la representación interna de estructuras compleja, respetando la interfaz común de la clase Builder.  Se independiza el código de construcción de la representación. Las clases concretas que tratan las representaciones internas no forman parte de la interfaz del Builder.  Cada ConcreteBuilder tiene el código específico para crear y modificar una estructura interna concreta.  Distintos Director con distintas utilidades (visores, parsers, etc) pueden utilizar el mismo ConcreteBuilder.  Permite un mayor control en el proceso de creación del objeto. El Director controla la creación paso a paso, solo cuando el Builder ha terminado de construir el objeto lo recupera el Director. 22 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Template Method Patrón de comportamiento. Intención: Definir el esqueleto de un algoritmo en una operación mientras se difieren algunos pasos en la subclase. Beneficios:  Flexibilidad y re uso  Fácil de modificar algoritmos (es la intención) Strategy Patrón de comportamiento. Permite mantener un conjunto de algoritmos de entre los cuales el objeto cliente puede elegir aquel que le conviene más e intercambiarlo dinámicamente en tiempo de ejecución según sus necesidades. 23 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Fachada Patrón estructural. Intención: Interfaz unificada para un conjunto de interfaces en un subsistemas la fachada define una interfaz que hace más fácil de usar los subsistemas. Es una clase que representa un subsistema entero. Motivación: Reduce la complejidad y el número de dependencias entre subsistemas Aplicación: Se aplicará el patrón fachada cuando se necesite proporcionar una interfaz simple para un subsistema complejo, o cuando se quiera estructurar varios subsistemas en capas, ya que las fachadas serían el punto de entrada a cada nivel. Otro escenario proclive para su aplicación surge de la necesidad de desacoplar un sistema de sus clientes y otros subsistemas, haciéndolo más independiente, portable y reutilizable. Conceptos y principios de diseño SOLID 24 Descargado por Thomas Mcculloch ([email protected])  lOMoARcPSD|44282546 Responsabilidad única (Single Responsability Principle) Una clase solo debe tener una razón por la cual cambiar. Si una clase tiene m{as de una responsabilidad tiende a tener baja cohesión. Principio de abierto-cerrado (Open Closed Principle) Las entidades de software deben ser abiertas para la extensión y cerradas para la modificación.  Abierto: Se debe poder cambiar el comportamiento de un módulo ante cambios en la aplicación o para satisfacer nuevos requerimientos.  Cerrado: El código del módulo no debe cambiar debido a que otros módulos lo pueden estar utilizando. Liskov (Liskov Substitution Principle) Método que utilizan referencias a clases base deben poder utilizar sin saberlo objetos de clases derivadas. Este principio asegura que un método desconoce las subclases de las clases que referencia y por lo tanto que no se vea afectado por las derivaciones e la clase. Este principio se apoya en el concepto de tipo y subtipo es decir, cuando se hereda de una clase base, debemos ser capaces de sustituir las subclases por la clase base sin que suceda ningún tipo de problema. Separación de la interfaz (Interface segregation principle) Todo componente debe consistir en dos partes:  Interfaz: define la funcionalidad que el componente provee y como se utiliza.  Implementación: Incluye el código y estructura de datos que implementan la interfaz Principio de dependencias acíclicas (Dependency Inversion Principle) La estructura de dependencia entre paquetes debe formar un grafo dirigido y acíclico. Rompiendo los ciclos: Utilizar el principio de inversión de dependencias o crear un nuevo paquete que agrupe las clases de las cuales ambos paquetes del ciclo dependen. Diseños estables: Las dependencias entre paquetes deben ser acordes con la estabilidad de los paquetes. Un paquete debe depender solo de paquetes más estables que él. 25 Descargado por Thomas Mcculloch ([email protected])