Para mí:
Un ayudante es una fachada, o codifica/decodifica un formato de datos particular y no tiene estado entre las llamadas.
Una utilidad es para codificar/decodificar un formato o hacer IO, y si crea conexiones a menudo no mantiene las conexiones ni mantiene los archivos abiertos entre las llamadas.
Un administrador es como un Ayudante pero tiene un estado entre llamadas.
Una fábrica es una clase que obtiene o crea y luego devuelve un objeto (ya sea uno personalizado o uno de API).
Simple y Predeterminado a menudo simplemente significa clase base.
A Mi "clase" tiende a ser para ideas previas al vuelo y ejemplos de código, aunque a veces se utiliza en el código de producción, por ejemplo, para MyApplication y MyView (esencialmente para nombrar singletons).
Estos nombres de clase son de facto. Estos son los significados que creo y veo más a menudo, pero a menudo se ven esquemas de nomenclatura e inconsistencias contradictorios. No son nombres de patrones de diseño formales y, en la práctica, la elección de cualquiera de estos nombres parece ser casi arbitraria. Algunas personas etiquetan todas sus clases que son seguras para subprocesos con uno de estos nombres y aquellos que no están con otro de ellos.
A menudo también veo que se da un nombre de "Administrador" a una clase que realiza una función ORM like con objetos o claves, o a un objeto que arbitra las conexiones.
EDITAR
Veo una aplicación que está construido sobre un marco como suele tener estos objetos principales:
- proceso oficial de entrada/salida/manipulación talón de
- Una aplicación (Singleton) eventos objeto (hace referencia a un modelo de datos jerárquico y tal vez a objetos de tareas)
- Un administrador de base de datos
- A networ gerente k
- Una interfaz de usuario (que hace referencia o no hace referencia a un modelo de vista dependiendo de su creencia religiosa)
- clases de ayuda/Utilidad/Factory
- pegamento Varios códigos
- archivos auxiliares
Veo que centrarme en maximizar la capacidad de prueba y minimizar el área de superficie de estas interfaces es más importante que el nombre de los paquetes y el nombre de los archivos; Creo que debe seguir su propia nariz para conocer los desgloses detallados y la denominación de su proyecto. La división de código en diferentes archivos para propósitos de SCM es especialmente importante para los archivos compartidos de los que depende más de un punto anterior.
EDITAR
utilizo singleton, mosca, compuesto, iterador, recuerdo, observador, el estado, la estrategia como una cuestión de rutina. Utilizo fachada, proxy, cadena de responsabilidad entre los módulos y en el código de UI. Uso ocasionalmente fábrica, prototipo y constructor en sistemas de datos complejos, y plantilla y visitante cuando un sistema es particularmente complejo conceptualmente. De vez en cuando uso adaptador, puente, fábrica, fábrica abstracta, decorador cuando el comportamiento es complejo. Raramente uso el intérprete y utilizo el mediador para ayudarme a escribir un código más general en ciertos casos. Personalmente, no me gusta nombrar mis clases después de GoF, pero mucha gente está muy contenta, puede ser una buena idea y no estoy en contra de la práctica. Puede ser muy útil y si hace felices a la gente y ayuda a aclarar a todo el mundo lo que está sucediendo en una instancia particular, entonces eso es genial.
Siento que llamar a mi objeto de aplicación Singleton, Composite o ChainOfResponsibilityLink (?) No me sienta bien, y que llamar a mi red y mis adaptadores de código de base de datos no me hace sentir bien, así que los llamo Gerentes.Y llamo a muchas cosas que quizás deberían llamarse Fachadas en GoF, Helpers o Utilities porque creo que es más claro lo que significa.
No estoy seguro de qué tiene que ver esto con "arquitectura" - parece que solo está preguntando sobre "definiciones aceptadas" –
No dude en volver a titular para algo más apropiado – slimbo
Estrictamente hablando, esto no es arquitectura como nada aquí debería (¡teóricamente!) determinar la experiencia del usuario o los contenidos del manual del producto. ¡Los detalles de mantenimiento no deben formar parte de la experiencia del producto ni de los conocimientos del usuario! Realmente es diseño, pero al menos es el diseño desde el punto de vista de un arquitecto y, por ese motivo, podría permanecer bajo una etiqueta de arquitectura. – martinr