design-patterns - software - patrones en java ejemplos
¿Diferencia entre el patrón compuesto y el patrón decorador? (7)
¿Cuál es la diferencia entre el patrón compuesto y el patrón decorador?
Un decorador se puede ver como un compuesto degenerado con solo un componente. Sin embargo, un decorador agrega responsabilidades adicionales, no está destinado a la agregación de objetos.
Esto es lo que se dice en "Patrones de diseño: elementos del software orientado a objetos reutilizables" por la pandilla de cuatro.
Diferencias en la estructura
Aquí están los diagramas de clase del libro de GoF, reproducidos usando PlantUML.
Diferencias en la intención
La intención de Decorator es decorar un solo componente (el diagrama UML realmente debe mostrar una multiplicidad de uno para el componente decorado), mientras que la intención de Composite es agrupar los componentes como un todo en el compuesto (de nuevo, el UML debería mostrar un Compuesto que contiene uno o más componentes).
Decorator tiene el objetivo de agregar comportamiento (mejorar el comportamiento del método Operation() ) a través de ConcreteDecorators, mientras que Composite pretende recopilar componentes.
El patrón Decorator se puede usar para ampliar (decorar) la funcionalidad de un determinado objeto de forma estática o, en algunos casos, en tiempo de ejecución, independientemente de otras instancias de la misma clase.
Es posible debido a la composición: Decorator contiene componentes y al mismo tiempo implementa la interfaz de componentes.
El patrón Composite describe que un grupo de objetos se debe tratar de la misma manera que una instancia única de un objeto. La intención de un compuesto es "componer" objetos en estructuras de árbol para representar jerarquías de parte-todo.
La implementación del patrón compuesto permite a los clientes tratar objetos individuales y composiciones de manera uniforme.
Aunque la estructura parece ser la misma, los casos de intención y uso son diferentes.
Casos de uso para el patrón Decorator :
- Las responsabilidades y comportamientos del objeto se deben agregar / eliminar dinámicamente
- Implementaciones concretas deben estar desacopladas de las responsabilidades y comportamientos
- la creación de subclases es demasiado costosa para agregar / eliminar dinámicamente responsabilidades
Decorator clave entre estos dos patrones:
- Decorator está diseñado para permitirle agregar responsabilidades a los objetos sin crear subclases. El enfoque de Composite no está en el embellecimiento sino en la representación
- Decorator agrega / elimina responsabilidades adicionales; no está destinado a la agregación de objetos.
Publicaciones útiles en SE para una mejor comprensión:
La diferencia probablemente sea más de propósito que de implementación. En algunos casos, el patrón compuesto es preferible a la subclasificación. Por ejemplo, puede agregar la funcionalidad que desea que tenga una clase al agregar instancias de otras clases y luego exponer la funcionalidad a través de una interfaz de reenvío.
Los decoradores le permiten agregar funcionalidad, normalmente una única capacidad, a una clase sin clientes de las instancias de la clase que necesitan saber que hay un decorador allí. Por ejemplo, un decorador "login_required" en una vista en Django plantea una excepción si el usuario no está conectado, pero de lo contrario la vista se comporta como lo haría sin el decorador.
En ambos casos, tienes un objeto incrustado dentro de otro, pero lo que estás tratando de lograr es discutiblemente diferente.
La estructura del patrón compuesto y el decorador tienen el mismo aspecto, pero tienen una intención diferente.
Composite proporciona una interfaz unificada para una hoja y un compuesto.
El decorador decorador brinda una función adicional a la hoja, al tiempo que proporciona una interfaz unificada.
Ejemplos
Patrón compuesto : carpetas clásicas de Windows y archivos. Las carpetas de Windows son compuestas. los archivos son hojas. Un doble clic en cualquiera de ellos abre el archivo / carpeta; haga doble clic en la interfaz unificada.
Patrón de decorador : Buffered io - java.io.FileWriter y java.io.BufferedWriter extienden java.io.Writer . java.io.BufferedWriter es compuesto y FileWriter es hoja. BufferedWriter agrega responsabilidad adicional (o función) de almacenamiento en búfer a FileWriter . write() método write() es una interfaz unificada, mientras que el almacenamiento en búfer es una característica adicional.
Por lo general van mano a mano. En eso, usar el patrón compuesto a menudo conduce a usar también el patrón de decorador.
El patrón compuesto le permite construir una estructura jerárquica (como un árbol de elementos) de forma que permita que su código externo vea toda la estructura como una sola entidad. Entonces la interfaz con una entidad hoja es exactamente la misma que la entidad para una entidad compuesta. Entonces, la esencia es que todos los elementos en su estructura compuesta tienen la misma interfaz, aunque algunos son nodos hoja y otros son estructuras enteras. Las interfaces de usuario a menudo usan este enfoque para permitir una compibilidad fácil.
http://en.wikipedia.org/wiki/Composite_pattern
El patrón de decorador permite que una entidad contenga por completo a otra entidad de modo que el decorador se vea idéntico a la entidad contenida. Esto le permite al decorador modificar el comportamiento y / o el contenido de lo que está encapsulando sin cambiar la apariencia externa de la entidad. Por ejemplo, puede usar un decorador para agregar salida de registro en el uso del elemento contenido sin cambiar el comportamiento del elemento contenido.
Compuesto:
- Es una estructura de árbol que usa recursividad.
- Leaf y Composite tienen la misma interfaz
- Unidad entre objetos
Decorador:
- Contiene otra entidad
- Agregar nueva funcionalidad a un objeto compuesto sin modificarlo.