Diseñando para el cambio.
La clave para maximizar la reutilización del software consiste en anticipar los nuevos requerimientos y los cambios sobre los requerimientos existentes, y en diseñar tus sistemas para que ellos puedan evolucionar de forma acorde
La clave para maximizar la reutilización del software consiste en anticipar los nuevos requerimientos y en diseñar tus sistemas para que ellos puedan evolucionar de forma acorde
.
Diseñando para el cambio. Para diseñar un sistema que sea robusto a los cambios...
tú debes considerar como podría necesitar el sistema cambiar a lo largo de su ciclo de vida (tiempo de vida)
en realidad no se pueden hacer cambios en el sistema a lo largo de su ciclo de vida (tiempo de vida)
.
Diseñando para el cambio.
Un diseño que no toma en cuenta el cambio tiene un mayor riesgo de tener que ser rediseñado en el futuro
Un diseño que no toma en cuenta el cambio tiene un menor riesgo de tener que ser rediseñado en el futuro
.
Diseñando para el cambio. Un diseño que no toma en cuenta el cambio tiene un mayor riesgo de tener que ser rediseñado en el futuro: esto podría consistir en: redefinición de clases reimplementación modificación de los clientes volver a hacer las pruebas del software (retesting) usar exclusivamente herramientas CASE.
Indica la correcta:
Tener que rediseñar afecta a muchas partes de un sistema software, y los cambios no anticipados son invariablemente muy caros
Tener que rediseñar afecta a pocas partes de un sistema software, y los cambios no anticipados no suelen ser muy caros
.
Los patrones de diseño te ayudan a evitar el coste de rediseñar el software (los cambios no anticipados son invariablemente muy caros) de formas específicas. Cada patrón de diseño permite que algunos aspectos de la estructura del sistema varíen independientemente de otros aspectos de la estructura del sistema, por lo tanto cada patrón de diseño hace que el sistema sea más robusto para una tipo particular de cambio
Cada patrón de diseño permite que algunos aspectos de la estructura del sistema varíen independientemente de otros aspectos de la estructura del sistema, por lo tanto cada patrón de diseño hace que el sistema sea más robusto para todo tipo de cambios
.
Causas de rediseño y el patrón de diseño que lo soluciona:
1. Crear un objeto especificando explícitamente una clase: Especificar el nombre explícito de una clase cuando creas un objeto te vincula a una implementación particular en vez de a una interface particular. Esta vinculación complica los cambios futuros. Para evitar esto hay que crear los objetos indirectamente
Patrones de diseño que resuelven esto: abstract factory, factory method y prototype
1. Crear un objeto especificando implícitamente una clase: Especificar el nombre implícito de una clase cuando creas un objeto te vincula a una interface particular en vez de a una implementación particular. Esta vinculación complica los cambios futuros. Para evitar esto hay que crear los objetos indirectamente
Patrones de diseño que resuelven esto: abstract factory, factory method y prototype
1. Crear un objeto especificando explícitamente una clase: Especificar el nombre explícito de una clase cuando creas un objeto te vincula a una implementación particular en vez de a una interface particular. Esta vinculación complica los cambios futuros. Para evitar esto hay que crear los objetos indirectamente
Patrones de diseño que resuelven esto: chain of responsability y command
1. Crear un objeto especificando implícitamente una clase: Especificar el nombre implícito de una clase cuando creas un objeto te vincula a una interface particular en vez de a una implementación particular. Esta vinculación complica los cambios futuros. Para evitar esto hay que crear los objetos indirectamente
Patrones de diseño que resuelven esto: chain of responsability y command
.
Causas de rediseño y el patrón de diseño que lo soluciona:
2. Dependencia de operaciones específicas. Cuando tú especificas una operación particular, tú te vinculas a una forma específica de satisfacer una petición. Si evitas las peticiones vinculadas directamente a un código específico consigues que sea más fácil cambiar la forma en que una petición se satisface en ambos casos: tiempo de compilación y tiempo de ejecución
Patrones de diseño que resuelven esto: chain of responsability y command
2. Dependencia de operaciones específicas. Cuando tú especificas una operación abstracta, tú te vinculas a una forma específica de satisfacer una petición. Si evitas las peticiones vinculadas directamente a un interfaz abstracto consigues que sea más fácil cambiar la forma en que una petición se satisface en ambos casos: tiempo de compilación y tiempo de ejecución
Patrones de diseño que resuelven esto: abstract factory, factory method y prototype
2. Dependencia de operaciones específicas. Cuando tú especificas una operación particular, tú te vinculas a una forma específica de satisfacer una petición. Si evitas las peticiones vinculadas directamente a un código específico consigues que sea más fácil cambiar la forma en que una petición se satisface en tiempo de compilación
Patrones de diseño que resuelven esto: chain of responsability y command
.
Causas de rediseño y el patrón de diseño que lo soluciona:
3. Dependencia de la plataforma hardware o de la plataforma software. Las interfaces externas de los sistemas operativos y las interfaces de programación de aplicaciones (application programming interface = API) son diferentes en diferentes plataformas hardware y en diferentes plataformas software. El software que depende de una plataforma particular será más difícil de migrar a otras plataformas. Podría ser incluso difícil mantener ese software dependiente de la plataforma nativa actualizado en su propia plataforma nativa a medida que está cambia. Es importante por tanto diseñar tu sistema para limitar las dependencias con las plataformas hardware y software específicas.
Patrones de diseño que resuelven esto: abstract factory y bridge
3. Dependencia de la plataforma hardware o de la plataforma software. Las interfaces externas de los sistemas operativos y las interfaces de programación de aplicaciones (application programming interface = API) son diferentes en diferentes plataformas hardware. El software que depende de una plataforma particular será más difícil de migrar a otras plataformas. Podría ser incluso difícil mantener ese software dependiente de la plataforma nativa actualizado en su propia plataforma nativa a medida que está cambia. Es importante por tanto diseñar tu sistema para limitar las dependencias con las plataformas hardware y software específicas.
Patrones de diseño que resuelven esto: abstract factory y bridge
3. Dependencia de la plataforma hardware o de la plataforma software. Las interfaces externas de los sistemas operativos y las interfaces de programación de aplicaciones (application programming interface = API) son diferentes en diferentes plataformas software. El software que depende de una plataforma particular será más difícil de migrar a otras plataformas. Podría ser incluso difícil mantener ese software dependiente de la plataforma nativa actualizado en su propia plataforma nativa a medida que está cambia. Es importante por tanto diseñar tu sistema para limitar las dependencias con las plataformas hardware y software específicas.
Patrones de diseño que resuelven esto: abstract factory y bridge
3. Dependencia de la plataforma hardware o de la plataforma software. Las interfaces externas de los sistemas operativos y las interfaces de programación de aplicaciones (application programming interface = API) son diferentes en diferentes plataformas hardware y en diferentes plataformas software. El software que depende de una plataforma particular será más difícil de migrar a otras plataformas. Podría ser incluso difícil mantener ese software dependiente de la plataforma nativa actualizado en su propia plataforma nativa a medida que está cambia. Es importante por tanto diseñar tu sistema para limitar las dependencias con las plataformas hardware y software específicas.
Patrones de diseño que resuelven esto: abstract factory y factory method
.
Causas de rediseño y el patrón de diseño que lo soluciona:
4. Dependencia de las representaciones de los objetos y de las implementaciones de los objetos. Puede haber clientes que saben cómo se representa un objeto, cómo se guarda un objeto, dónde está localizado un objeto o cómo está implementado un objeto, entonces esos clientes necesitan cambiar cuando cambia el objeto. Esconder todo esta información de los clientes permite los cambios en cascada
Patrones de diseño que resuelven esto: abstract factory, bridge, memento y proxy
4. Dependencia de las representaciones de los objetos y de las implementaciones de los objetos. Puede haber clientes que saben cómo se representa un objeto, cómo se guarda un objeto, dónde está localizado un objeto o cómo está implementado un objeto, entonces esos clientes no necesitan cambiar cuando cambia el objeto. Esconder todo esta información de los clientes permite los cambios en cascada
Patrones de diseño que resuelven esto: abstract factory, builder, memento y proxy
.
Causas de rediseño y el patrón de diseño que lo soluciona:
5. Dependencias de los algoritmos. Los algoritmos a menudo son extendidos, optimizados y reemplazados durante el desarrollo y la reutilización. Los objetos que dependen de un algoritmo tendrán que cambiar cuando el algoritmo cambie. Por lo tanto los algoritmos que es probable que cambien deben ser aislados
Patrones de diseño que resuelven esto: builder, iterator, strategy, template method y visitor
5. Dependencias de los algoritmos. Los algoritmos a menudo son extendidos, optimizados y reemplazados durante el desarrollo y la reutilización. Los objetos que dependen de un algoritmo no tendrán que cambiar cuando el algoritmo cambie. Por lo tanto los algoritmos que es probable que cambien deben ser aislados
Patrones de diseño que resuelven esto: abstract factory, iterator, strategy, template method y visitor
.
Causas de rediseño y el patrón de diseño que lo soluciona:
6. Alto acomplamiento. Las clases que están altamente acopladas entre sí son muy difíciles de reutilizar aisladamente porque como estamos diciendo, estas clases dependen de otras. El alto acoplamiento nos lleva sistemas monolíticos, en los cuales tú no puedes cambiar o borrar una clase sin entender y cambiar muchas otras clases. El sistema es una masa densa que es muy difícil de aprender, migrar y mantener.
El bajo acoplamiento aumenta la probabilidad de que una clase pueda ser reusada aisladamente y el bajo acoplamiento también aumenta la probabilidad de que un sistema pueda ser aprendido, migrado, modificado y extendido de forma mucho más fácil. Los patrones de diseño usan técnicas como el acoplamiento abstracto y el uso de capas para crear sistemas con bajo acoplamiento.
Patrones de diseño que resuelven esto: abstract factory, bridge, chain of responsability, command, facade, mediator y observer
6. Alto acomplamiento. Las clases que están altamente acopladas entre sí son muy fáciles de reutilizar aisladamente porque como estamos diciendo, estas clases dependen de otras. El alto acoplamiento nos lleva sistemas monolíticos, en los cuales tú no puedes cambiar o borrar una clase sin entender y cambiar muchas otras clases. El sistema es una masa densa que es muy difícil de aprender, migrar y mantener.
El bajo acoplamiento aumenta la probabilidad de que una clase pueda ser reusada aisladamente y el bajo acoplamiento también aumenta la probabilidad de que un sistema pueda ser aprendido, migrado, modificado y extendido de forma mucho más fácil. Los patrones de diseño usan técnicas como el acoplamiento abstracto y el uso de capas para crear sistemas con bajo acoplamiento.
Patrones de diseño que resuelven esto: abstract factory, bridge, chain of responsability, command, facade, mediator y observer
6. Alto acomplamiento. Las clases que están altamente acopladas entre sí son muy difíciles de reutilizar aisladamente porque como estamos diciendo, estas clases dependen de otras. El alto acoplamiento nos lleva sistemas monolíticos, en los cuales tú no puedes cambiar o borrar una clase sin entender y cambiar muchas otras clases. El sistema es una masa densa que es muy difícil de aprender, migrar y mantener.
El bajo acoplamiento aumenta la probabilidad de que una clase pueda ser reusada aisladamente y el bajo acoplamiento también aumenta la probabilidad de que un sistema pueda ser aprendido, migrado, modificado y extendido de forma mucho más fácil. Los patrones de diseño usan técnicas como el acoplamiento abstracto y el uso de capas para crear sistemas con bajo acoplamiento.
Patrones de diseño que resuelven esto: abstract factory, bridge, iterator, command, facade, mediator y observer
.
Causas de rediseño y el patrón de diseño que lo soluciona:
7. Extender la funcionalidad haciendo subclases (usando subclassing). Modificar un objeto haciendo subclassing no es muy fácil. Cada clase nueva tiene una implementación por encima (incialización, finalización, etc.). Definir una subclase también requiere una comprensión profunda de la clase padre (o de las clases padres). Por ejemplo, sobrescribir una operación podría requerir sobrescribir una o varias más. Una operación que se sobreescribe también podría necesitar llamar a una operación heredada. Además hacer subclassing puede llevar a una explosión de clases, porque tu podrías tener que crear muchas nuevas subclases para incluso una simple extensión.
La composición de objetos en general y la delegación en particular proporcionan alternativas flexibles a la herencia para combinar comportamiento. La nueva funcionalidad puede ser añadida a una aplicación componiendo objetos existentes de nuevas formas más que definiendo nuevas subclases de clases ya existentes. En cambio, el uso fuerte de la composición de objetos puede hacer el diseño más difícil de entender. Muchos patrones de diseño producen diseños donde tú puedes introducir funcionalidad personalizada definiendo una subclase y componiendo sus instancias (sus objetos) con otras instancias (con otros objetos).
Patrones de diseño que resuelven esto: bridge, chain of responsability, composite, decorator, observer y strategy
7. Extender la funcionalidad haciendo subclases (usando subclassing). Modificar un objeto haciendo subclassing no es muy fácil. Cada clase nueva tiene una implementación por encima (incialización, finalización, etc.). Definir una subclase también requiere una comprensión profunda de la clase padre (o de las clases padres). Por ejemplo, sobrescribir una operación podría requerir sobrescribir una o varias más. Una operación que se sobreescribe nunca necesita llamar a una operación heredada. Además hacer subclassing puede llevar a una explosión de clases, porque tu podrías tener que crear muchas nuevas subclases para incluso una simple extensión.
La composición de objetos en general y la delegación en particular proporcionan alternativas flexibles a la herencia para combinar comportamiento. La nueva funcionalidad puede ser añadida a una aplicación componiendo objetos existentes de nuevas formas más que definiendo nuevas subclases de clases ya existentes. En cambio, el uso fuerte de la composición de objetos puede hacer el diseño más fácil de entender. Muchos patrones de diseño producen diseños donde tú puedes introducir funcionalidad personalizada definiendo una subclase y componiendo sus instancias (sus objetos) con otras instancias (con otros objetos).
Patrones de diseño que resuelven esto: bridge, chain of responsability, iterator, decorator, observer y strategy
.
Causas de rediseño y el patrón de diseño que lo soluciona:
8. La falta de habilidad para alterar las clases convenientemente. A veces tú tienes que modificar una clase que no puede ser modificada convenientemente. Quizás tú necesitas el código fuente y no lo tienes (esto es muy común en las librerías de clases comerciales). O quizás cualquier cambio podría requerir modificar muchísimas subclases. Los patrones de diseño ofrecen formas de modificar clases en estas circunstancias.
Patrones de diseño que resuelven esto: adapter, decorator y visitor
8. La falta de habilidad para alterar las clases convenientemente. A veces tú tienes que modificar una clase que no puede ser modificada convenientemente. Quizás tú necesitas el código fuente y no lo tienes (esto es muy común en las librerías de clases comerciales). Cualquier cambio nunca requerirá modificar ninguna otra clase. Los patrones de diseño ofrecen formas de modificar clases en estas circunstancias.
Patrones de diseño que resuelven esto: adapter, bridge y visitor
.
Indica la correcta: Los patrones de diseño pueden ayudarte a que tu software sea flexible Los patrones de diseño solamente crean software rígido.
Se pueden estudiar los patrones de diseño estudiando el desarrollo de tres amplias clases de software: programas de aplicaciones, toolkits (kits de herramientas) y frameworks (infraestructuras software) programas de aplicaciones, implementaciones VHDL y frameworks (infraestructuras software).
|
