tipos patrones lista estructurales ejemplos diseño arquitectura design-patterns composite

design patterns - patrones - ¿Cuándo debería usar el patrón de diseño compuesto?



patrones de diseño web (10)

No entiendo cuando debería usar un patrón de diseño compuesto . ¿Qué tipo de beneficios obtendré de este patrón de diseño? Visité este sitio web, pero solo me dice sobre la estructura del patrón de diseño y no sobre los escenarios en los que se usa. Espero que sea beneficioso para los programadores como yo que están empezando a aprender el patrón de diseño.


A menudo utilizo el patrón de diseño compuesto para ocultar colecciones. En muchos casos, trabajamos con colecciones exactamente de la misma manera cuando hay muchos elementos y cuando solo hay un elemento en ellos.

Ese es el problema, porque la clase que contiene una colección se enjambrazó con bucles foreach que básicamente hacen lo mismo: recorrer todos los elementos y aplicar alguna función agregada.

Para resolver el problema, introduzco una interfaz que se implementa mediante el elemento individual y la clase que oculta la colección de esos elementos. El propósito de la clase compuesta es entonces contener todas las funciones agregadas que solían estar en la clase de cliente.

Puede encontrar algunos ejemplos útiles en este artículo: Trabajar con colecciones

Lo más común aquí es que Composite no representa necesariamente la relación parte-todo. Es posible introducir elementos compuestos solo para mover los bucles fuera del cliente.

Y aquí hay un ejemplo del ejemplo de aplicar el patrón Compuesto para ocultar partes detrás del elemento compuesto : Patrón de diseño compuesto


Citando de patrones de diseño ,

Use el patrón Compuesto cuando

  • desea representar jerarquías de objetos de una parte entera.
  • desea que los clientes puedan ignorar la diferencia entre composiciones de objetos y objetos individuales. Los clientes tratarán todos los objetos en la estructura compuesta uniformemente.

Un uso común es el utilizado como un ejemplo motivador en el libro, un sistema de visualización de ventanas gráficas que puede contener otras ventanas y elementos gráficos como imágenes y texto. El compuesto se puede componer en tiempo de ejecución, y el código del cliente puede manipular todos los elementos sin preocuparse por qué tipo es para operaciones comunes como el dibujo.


Composite Pattern permite a los clientes tratar objetos individuales y composiciones (de objetos individuales) uniformemente.
Por ejemplo, al hacer doble clic en la carpeta, debería abrir la carpeta. En el doble del archivo, debe abrirse en el Programa correspondiente.
La operación es la misma pero se comporta en función de si se trata de Objetos individuales o Composiciones

Interfaz común para objetos individuales y objetos compuestos

interface Data{ public void doubleClick(); }

Implementación individual de objetos

class File implements Data { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } @Override public void doubleClick() { System.out.println(this.getName()+" file is Opened in a Program "); } }

Implementación compuesta

class Folder implements Data { private String name; public String getName() { return name; } public void setName(String name) { this.name = name; } private List<Data> folder = new ArrayList<Data>(); @Override public void doubleClick() { System.out.println(this.getName() + " folder is Opened"); for(Data data : folder) { data.doubleClick(); } } public void add(Data data) { folder.add(data); } public void remove(Data data) { folder.remove(data); } }

Programa de cliente

public class CompositePattern { public static void main(String[] args) { Folder f1 = new Folder();f1.setName("Folder 1"); Folder f2 = new Folder();f2.setName("Folder 2"); Folder f3 = new Folder();f3.setName("Folder 3"); File file1 = new File();file1.setName("File 1"); File file2 = new File();file2.setName("File 2"); File file3 = new File();file3.setName("File 3"); File file4 = new File();file4.setName("File 4"); f1.add(file1); f2.add(file2); f3.add(f2); f3.add(file3); f3.add(file4); f1.doubleClick();f2.doubleClick();f3.doubleClick(); } }


Ejemplo de patrón de diseño compuesto en el mundo real, cuando tenemos posibilidades de tener instancias del mismo tipo de elemento principal dentro o tipo de componente.

Ejemplo: en sistemas de comercio de divisas Ex1

Puede tener un par de divisas cruzadas (AUD / EUR) = (AUD / USD y 1 / (EUR / USD)) el punto aquí es que su Instrumento (Cruzado) puede tener dos Instrumentos (Directos) dentro.

En otro ejemplo, tiene

Un Instrumento (Cruzado) e Instrumento (Directo) e Instrumento (Cruzado) que se pueden dividir adicionalmente para remolcar el Instrumento (Directo). SGD / CZK = USD / SGD (directo) y USD / CZK (cruzado) = USD / SGD (directo) y (1 / EUR / USD) (directo) y EUR / CZK (directo)

El punto aquí es que sigas dividiendo hasta que no encuentres todos los pares de divisas directos.

Arriba se puede implementar fácilmente usando el patrón de diseño compuesto.



Habiendo estudiado y probado recientemente, reconocí un concepto poderoso para tener en cuenta acerca de Composites.

Los materiales compuestos ocultan la complejidad que implican las colecciones, es decir, recorrerlas, clasificarlas, filtrarlas, etc., y te permiten tratarlas como si fueran un solo organismo.

Diga, usted tiene un perro en una perrera y muchos perros en otra. Desea alimentarlos y vacunarlos, pero no puede alimentarlos si comieron en una hora o alimentarlos si se vacunaron en las últimas cinco horas, o vacunarlos si vomitaban, etc.

Lo que es más importante, hay reglas de orden de empaque donde la raza A del perro come antes de la raza B, a menos que el perro raza C esté cerca y ladrando hasta la cima de sus pulmones.

Esto llegará rápidamente a un punto en el que simplemente no desea preocuparse por nada más que llamar a un ayudante y decirle que alimente a ''todos los perros''. O mejor, tres ayudantes para realizar un seguimiento de la alimentación, la vacunación y el vómito, ladridos y embalajes y todas las demás cosas increíbles.

Al llamar ayudantes, confiaste en el patrón de Composición. Simplemente ve y "alimenta" a cada criadero, ya sea un perro o un diez. Solo quiere que la perrera llena de perros la solucione por sí misma y descubra cómo se alimentan, porque tiene demasiado en sus manos en el cajero.

Entonces, para ti, un Perro es un IDog, que Feed (), Bark (), Vomit () y GetVaccine (). Una perrera también es un perro, a quien llamas kennel.Feed (). Estás listo. La perrera Kennel tiene que descubrir qué hacer ahora internamente. Puede tener un mecanismo de mantenimiento de tiempo para seguir la alimentación de cada perro y otros tiempos de funcionamiento corporal. Todo está perfectamente encapsulado.


La respuesta debería ser:

Componga objetos en estructuras de árbol para representar jerarquías de partes enteras. Composite permite a los clientes tratar objetos individuales y composiciones de objetos de manera uniforme.

  • Composición recursiva
  • "Los directorios contienen entradas, cada una de las cuales podría ser un directorio".
  • 1-a-muchos "tiene una jerarquía" arriba de "es una"

copiado de un foro.


Puede encontrar que es imprescindible cuando trabajará con binary trees u otras complex data structures like list of lists of lists , etc ... luego, cuando cada elemento (clase) implemente 1 interfaz, puede hacer lo mismo métodos en 1 hoja o en un grupo completo de ellos: protección, agregar, eliminar, mover ... lo que sea, lo que has implementado correctamente. Es muy útil y simple.


Un compuesto es un patrón que es útil en cualquier momento que necesite tratar selectivamente a un grupo de objetos que son parte de una jerarquía como "lo mismo" cuando en realidad son diferentes. Típicamente, los ejemplos usados ​​hablan en términos de tratar hojas y nodos de la misma manera, pero el patrón también se puede extender a listas heterogéneas.

Por ejemplo, considere una visita al médico. Cuando acude a un médico, suceden varias cosas, por lo general, primero ve a una enfermera o un asistente, le toman la temperatura, etc. Luego, el médico realiza un examen y hace diagnósticos. Entonces el médico puede hacer algún tratamiento, pero a menudo la enfermera regresa para terminar. Y diferentes actividades se realizan durante la visita. Usted tiene observaciones como el peso y la temperatura. Pero un laboratorio, por ejemplo, será un objeto diferente porque a menudo requiere una muestra que luego se puede enviar y requiere que los resultados se graben en una fecha posterior.

Entonces tenemos un software que permite registrar todo esto y generalmente creará algún tipo de jerarquía con nodos como:

Encuentro:
PreExam
Examen
Tratamiento

y debajo de cada uno de estos nodos tendrá una variedad de entradas tales como diagnóstico, observación, procedimiento de laboratorio, diagnóstico, inyección, etc.

Todo está muy bien, y terminas con un registro jerárquico estructurado, aunque muy complejo, del encuentro.

Ahora supongamos que necesita generar facturación. De repente, te enfrentas a un requisito muy diferente. Se requirió su registro médico para crear una imagen muy precisa del encuentro. En la facturación, aunque no le importa quién hizo qué o en qué orden, de hecho, realmente no le importa qué actividad hay más allá de un código de facturación. Simplemente desea una única lista de actividades facturables, es decir, códigos.

Esta información no solo está integrada en un registro, sino que también es muy difícil de atravesar porque contiene una gran cantidad de objetos diferentes. También es variable en la estructura jerárquica: si tiene un clavo en la cabeza, pueden omitir cualquier tipo de preexamen o examen para ese caso e ir a tratamiento. Si ingresa para que le quiten los puntos, es posible que no haya ningún examen o examen previo. Un examen físico anual no tiene tratamiento. etc. Muy difícil de enumerar este tipo de gráfico de objetos.

Un patrón compuesto resuelve todo esto. Usted define una interfaz común o clase base para todos los objetos. Llamémoslo "CareEntry". CareEntry tiene una propiedad BillingCode. Ahora su Encounter puede parecer un contenedor simple con solo objetos CareEntry dentro. Su servicio de facturación ahora puede simplemente enumerar todo dentro sin tener que preocuparse de si algo es un nodo (Examen previo, Examen) versus una hoja (temperatura de peso), o en qué nodo se encuentra el objeto (Examen Preexam, etc.) o cuál es el tipo real del objeto es (laboratorio, inyección, etc.). Todo es también un CareEntry y se trata uniformemente. Simplemente enumera todos los objetos CareEntry en un Encounter y recoge cada uno que tenga un código de facturación no nulo y listo. Es tan simple como eso.


si desea construir objetos similares anidados, puede optar por un patrón de diseño compuesto, por ejemplo: en tiempo real si desea mostrar la estructura de árbol para el empleado de la oficina en función de la jerarquía