Dónde poner métodos compartidos comunes

9

Tengo un montón de métodos que se usan comúnmente en todas partes. En este momento, el archivo de código se llama globales, para representar el hecho de que son ... de hecho ... globales.

Sin embargo, no me gusta esto.

Quiero agruparlos en una clase y pasar una interfaz. Solo haré una instancia, pero no estoy cayendo en la trampa de Singleton aquí.

En primer lugar, ¿cómo debo nombrar la clase? Quiero evitar el nombre global porque me temo que los encargados del mantenimiento se equivocarían.

Además, ¿cómo debería considerar dividir este conjunto de métodos para que el comportamiento pueda cambiar y adaptarse?

El conjunto de métodos contiene cosas como:

Tablas de conversión
Interacción portapapeles
Administrar fuentes construidas
Métodos comunes de dibujo
Proporcionar una interfaz con acceso a los recursos utilizados con frecuencia.

c#

— Lee Louviere
fuente

¿Son estos métodos de Util puro que no guardan el estado o guardan el estado?

— TheLQ

+1 por no caer en la trampa de singleton.

— Caleb

@TheLQ No necesariamente guardarán el estado, pero mantendrán los datos constantes (como los gráficos de conversión) por conveniencia.

— Lee Louviere

4

El espacio de nombres podría ser [application].Common.Shared

Las clases pueden ser nombradas:

ConversionLookup
ClipboardCommunication
FontManager
DrawingUtility

Rompería las clases porque parece que hacen cosas diferentes.

— Jon Raynor
fuente

1

Si va a hacer una instancia, prácticamente tiene un singleton. Además, a lo que la gente normalmente se referiría si hablaran de una trampa de singleton es que los singletons son globales, y es mejor que la mayoría de las clases no sean globales. Entonces también podrías tener un singleton. Si puede pasar razonablemente una interfaz a objetos que quieran llamarla, entonces no es realmente global.

Además, poner todo en una bolsa de métodos globales hace que sea difícil hacer que el comportamiento cambie y se adapte, ya que no solo cada cambio a un método requiere una nueva subclase, sino que cada combinación de cambios necesitaría su propia subclase.

Recomendaría tener singletons para cada uno que realmente sea global (tomaré su palabra de que todos lo son) y algún tipo de registro o fábrica que le brinde una instancia (lo que significa que puede implementar como singleton o no, ya que la interfaz será no hacer promesas). Los nombraría en función de lo que hacen desde la perspectiva de la persona que llama.

— psr
fuente

1

Normalmente pongo este tipo de cosas en sus propios nombres de ensamblaje algo así como "foo.Common" en espacios de nombres como "foo.Common.Collections" o "foo.common.UI", etc., luego puedo hacer referencia al ensamblaje en cualquier proyecto Los necesito.

— Muad'Dib
fuente