¿Qué convención de nomenclatura utilizas para el patrón de decorador? [cerrado]

Question

Recientemente, realmente realmente asimilé la inyección de dependencia y la maravilla del patrón de diseño de Decorator y lo estoy usando por todas partes.

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

¿Qué hacen ustedes?

Answer 1

Evito usar nombres de patrones de diseño. Creo que esto pertenece a la documentación, en cualquier lugar. Nombre la clase / función del decorador después de lo que hace o representa. El hecho de que decora o une o vincula o representa o representa de nuevo 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.

Answer 2

Tome un ejemplo del IO Framework de la API de Java. Utiliza el patrón decorador ampliamente, pero los nombres de las clases no reflejan esto. Por ejemplo, un BufferedReader puede decorar un FileReader, pero su nombre se debe a su función: lectores.

Agregar decorador al nombre conduciría a más problemas si también incorpora otros patrones que involucran las mismas clases, como suele ser el caso. Puede terminar con una clase llamada MyDecoratorStrategyComponent.

Answer 3

Llámalo como lo hace.

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

• PrintDisasterRecovery - Excepción manejo
• PrintQueuer: lo convierte en un llamada asíncrona

Estos capítulos heredan de PrintDecorator, por lo que si alguien mira debajo de las cubiertas, puede ver lo que está sucediendo.

Answer 4

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 servidores proxy, 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 el sufijo -bridge de manera apropiada?)