software reusable patterns pattern oriented latest gof español edition language-agnostic design-patterns naming-conventions decorator

language agnostic - reusable - ¿Qué convención de nomenclatura utilizas para el Patrón Decorador?



design patterns wikipedia (4)

Recientemente realicé realmente la inyección de dependencia y la maravilla del patrón de diseño del Decorador y lo estoy usando por todos lados.

Sin embargo, tan maravilloso como es, una cosa con la que he estado teniendo problemas es nombrar mis clases de decorador, así que me gustaría saber qué hacen los demás. ¿Siempre agregas la palabra Decorador? ¿Incorporas el nombre de la interfaz a su decoración? ¿Obtienen su propio espacio de nombres?

¿Qué hacen chicos?


Evito usar nombres de patrones de diseño. Creo que esto pertenece a la documentación si está en alguna parte. Nombra la clase / función del decorador después de lo que hace o representa. El hecho de que adorna o puentea o enlaza o representa o re-representa es de poca importancia.

Cada vez que nombra una cadena, ¿agrega un sufijo de cadena? Suena como hgrnNotation para mí, y eso es algo que trato de evitar.


Generalmente, cuando el patrón está encapsulado en un objeto (frente a una colección de objetos), entonces es más claro y fácil incluir el nombre del patrón en la clase, en este caso usando Decorator como sufijo. Esto funciona bien para proxies, decoradores, fábricas, adaptadores, etc., pero no funciona para otros patrones donde se necesita un grupo de objetos en la implementación del patrón como un puente (es decir, ¿qué objeto tomaría aproximadamente el sufijo -bridge?)


Llámalo como lo hace.

Tengo un montón de decoradores para una interfaz IPrinter. Ellos se llaman:

  • PrintDisasterRecovery - Manejo de excepciones
  • PrintQueuer: lo convierte en una llamada asíncrona

Estos chats heredan de PrintDecorator, por lo que si alguien mira debajo de las cubiertas, pueden ver qué está sucediendo.


Tome un ejemplo del Marco IO de la API de Java. Utiliza el patrón de decorador de forma exhaustiva, pero los nombres de las clases no reflejan esto. Por ejemplo, un BufferedReader puede decorar un FileReader pero llevan el nombre de su función - Readers.

Agregar el decorador al nombre generaría más problemas si también incorpora otros patrones que involucren las mismas clases que con frecuencia. Puede terminar con una clase llamada MyDecoratorStrategyComponent.