sirven - Anotaciones de Java para patrones de diseño
notacion en java (10)
Lo que sería mejor sería usar anotaciones para construir realmente la plantilla estándar para un Constructor. Seamos realistas, la mayoría son bastante estándar.
@Builder("buildMethodName")
Class Thing {
String thingName;
String thingDescr;
}
Uso típico:
Thing thing =
new Thing.Builder().setThingName("X").setThingDescr("x").buildMethodName();
¿Hay algún proyecto que mantenga anotaciones para patrones?
Por ejemplo, cuando escribo un constructor, quiero marcarlo con @Builder .
Anotar de esta manera inmediatamente proporciona una idea clara de lo que implementa el código. Además, el Javadoc de la anotación @Builder puede hacer referencia a las explicaciones del patrón del constructor. Además, navegar desde el Javadoc de una implementación del constructor a @Builder Javadoc es más fácil anotando @Builder con @Documented .
Me estoy ralentizando la acumulación de un pequeño conjunto de anotaciones para patrones y modismos que tengo en mi código, pero me gustaría aprovechar un proyecto existente más completo, si existe. Si no hay tal proyecto, tal vez pueda compartir lo que tengo convirtiéndolo en un proyecto de anotación de patrón / modismo separado.
Actualización: he creado el proyecto Pattern Notes en respuesta a esta discusión. Contribuciones bienvenidas! Aquí está @Builder
Esto parece un mal uso de las anotaciones para mí. Claro, pude ver por qué es posible que desee observar qué patrón de diseño está ayudando a implementar una clase, pero el uso de Javadoc y / o el nombre de la clase parece más apropiado. El nombre del patrón que está utilizando no tiene ninguna importancia real para el código en sí ... los patrones son solo una guía para una forma frecuente de resolver un problema. Un comentario sería suficiente, en lugar de crear un nuevo archivo para cada patrón que use.
Esta es una solución interesante, pero me pregunto cuál es realmente el problema que estás resolviendo con esto. O en otras palabras, ¿qué obtienes al usar algo como esto lo que no obtienes con un comentario apropiado en la parte superior de tu clase sobre su uso?
Puedo pensar en algunos inconvenientes, pero no puedo pensar en los beneficios aparte de esta es la forma agradable y estandarizada para documentar el código.
Contras sería, a saber:
- una cosa más para que los programadores piensen, lo cual nunca es algo bueno
- Los patrones no anotados pueden ser confusos: alguien probablemente se olvidó de documentarlo, pero tal vez no sea un patrón ...
- ¿puedes anotar realmente todos los patrones ...? ¿Qué pasa con los patrones que no están vinculados a una sola clase / método, por ejemplo, patrón de arquitectura de tres niveles, grupo de subprocesos o incluso MVC?
Si también puede escribir un procesador de anotaciones que verifique ciertas propiedades del patrón, por ejemplo, verificando errores comunes al implementar el patrón, esto sería muy útil. Documentación para el compilador y el programador.
En primer lugar, lo que quiere hacer es documentar una intención (o intención s ).
Entonces, ¿por qué no utilizar una versión genérica de su anotación, algo así como @UsePattern que usa @Documented que es una anotación de marcador ( buen tutorial de IBM )? Lo que no me gusta es que la anotación se mantenga en tiempo de ejecución, lo cual es un desperdicio a menos que quiera afectar la semántica del programa.
O una etiqueta personalizada de Javadoc que parece más apropiada.
Parte de la información sobre la comparación: Comparación de anotaciones y etiquetas Javadoc con una bonita oración de resumen:
<< En general, si el marcado está destinado a afectar o producir documentación, probablemente debería ser una etiqueta javadoc; de lo contrario, debería ser una anotación. >>
También hubo / hubo algún debate sobre la documentación como anotación o como etiquetas javadoc .
De lo contrario, existe este documento de 2008 de Ciencias de la Computación: Implementación de patrones de diseño en Java y AspectJ , que fue presentado en OOPSLA 2008, que debería dar una indicación sobre su calidad.
Una buena cita de eso:
... la mera existencia de clases que contienen exclusivamente código de patrón sirven como registros de qué patrones se están utilizando. En los casos de AspectJ, observamos dos mejoras adicionales. En primer lugar, todo el código relacionado con una instancia de patrón particular está contenido en un único módulo (que define a los participantes, asigna roles, etc.). Esto significa que la descripción completa de una instancia de patrón está localizada y no se "pierde" [21] o "degenerada" [7] en el sistema. En segundo lugar, con el soporte actual de AspectJ IDE, todas las referencias, métodos recomendados, etc. son hipervínculos que le permiten al desarrollador una visión general de la asignación de roles y donde las operaciones conceptuales de interés son ...
Parece un mal uso de las anotaciones para mí. A menos que exista la intención de implementar el comportamiento con esas anotaciones, utilizaría el principio de KISS: Plain ol ''javadoc no tiene problema para documentar qué se supone que debe hacer el artefacto / be; doclets personalizados para extender javadoc; y google para aquellos que quieren saber para qué sirve un patrón X o Y (o un enlace a él en algún lugar de la web).
Existen excelentes explicaciones casi oficiales para la mayoría de los patrones que existen. ¿Por qué escribir el tuyo? ¿Hay información adicional que es crucial para el proyecto? Usar anotaciones para asegurarse de que uno puede navegar de un javadoc de una clase a un javadoc de patrones personalizados es como la historia del CEO que reunió a un equipo de desarrollo para crear un informe que combina los totales de dos informes trimestrales existentes: era demasiado difícil (y aún más barato) para sumar los totales de los dos con una calculadora 4 veces al año: - /
Michael Hunger y yo hemos comenzado un proyecto de código abierto para anotaciones para especificar a qué patrones pertenecen las clases. Estamos en las etapas iniciales, pero nos encantaría escuchar su opinión.
Me gustaría ir con el principio de KISS para que las personas puedan usar las anotaciones lo más fácil posible. Por ejemplo, si está escribiendo un adaptador, simplemente puede decir:
@AdapterPattern
public class EnumerationIteratorAdapter<T> implements Enumeration<T> {
...
}
Por supuesto, puede especificar más información si lo desea, por ejemplo, el rol, los participantes y un comentario. Esperamos que esto facilite a los desarrolladores marcar sus clases con claridad.
El inicio del proyecto está en http://www.jpatterns.org desde donde también puede acceder al árbol de fuentes inicial. Póngase en contacto conmigo en heinz en javaspecialists dot eu si desea contribuir al proyecto.
Heinz (El boletín de especialistas de Java)
Acabo de tropezar con otro artículo que es interesante para ti: Marcadores de diseño - Programación explícita para el resto de nosotros, que habla de interfaces de marcadores, como Serializable .
En sus palabras:
... solo porque una clase declara que "implementa Serializable" no significa que haya implementado correctamente el contrato de Serializable.
Como Java no puede decir realmente si se ha cumplido el contrato, usar la interfaz de marcador es más una promesa explícita del programador que tiene.
El beneficio que se pasa por alto de las interfaces de marcadores es que también documentan la intención de que se cumpla un contrato ...
¿Por qué las elecciones de diseño tradicionalmente no se han registrado en el código fuente? En su mayoría, porque no ha habido un lugar claro para ponerlos.
Incluso si cada clase de "enumeración segura" tenía un comentario que indicaba que seguía ese patrón, no se habría agregado ninguna elaboración (mucho menos información tutorial) porque uno tenía que copiarla repetidamente o, lo que es peor, colocarla esporádicamente en puntos arbitrarios.
Al crear los comentarios de JavaDoc adjuntos a cada interfaz de Design Marker, se puede agregar más detalles de los típicos porque los comentarios no necesitan repetirse en ningún otro lado.
También mencionan algunos inconvenientes, ¡esto es una buena comida!
En primer lugar, es una muy buena idea y solo estoy pasando el rato aquí porque busqué en Google una biblioteca de "anotación de patrón de diseño". ¡Bien, encontré esto! Lo verificaré y daré retroalimentación pronto.
Para todos los escépticos: lo siento, obviamente, la mayoría de ustedes no tienen mucha experiencia en el tema de los patrones de diseño. Por ejemplo, la publicación de Martin Harris del 3 de diciembre de 2009 a las 21:56 ... Entiendo que quisieras mantener tu "ejemplo" simple. Pero eso no es un Constructor en el sentido del Patrón de Diseño.
Lo mismo quiero decir a aquellos que no ven la utilidad en absoluto. Si las relaciones de las clases con respecto a sus roles en los patrones de diseño se anotan en la clase, puedo usar un generador para elaborar el código repetitivo. Veo todas las relaciones en la parte superior de la clase en el código fuente y puedo usar mis accesos directos IDE para navegar a las clases relevantes.
Si ha aprendido a pensar en patrones y todos los patrones son obvios en el código fuente (a través de comentarios o anotaciones), puede captar un sistema compuesto por 200 clases en menos de una hora.
En cuanto a sugerencias como usar @UsePattern () o @Builder ("buildMethodName") etc. ... aquí tenemos que preguntar, ¿cómo hacer que sea "typesave"? Después de todas esas cadenas son propensos a errores tipográficos.
Una ventaja de las anotaciones correctas es que puede anotar roles ... La mayoría de los patrones de diseño no constan de una sola clase (como Singleton) sino de varias clases que trabajan juntas. Por ejemplo, si tiene un constructor, el resultado (anotado con @Product) también podría ser un @Composite. Entonces, las partes que el constructor está reuniendo serán @Component (con respecto a @Composite) y @Part (con respecto a @Builder y @Product).
Quizás el mejor argumento para tales anotaciones sería java.lang.class, para que pueda expresar eso.
De todos modos, solo unos pocos pensamientos ... No puedo esperar para llegar a casa y jugar con lo que tienes hasta ahora ^^