¿Gestión de recursos compartidos entre clases?

Question

Imagine que tengo varios componentes de visor que se usan para mostrar texto y tienen pocos modos que el usuario pueda cambiar (diferentes preajustes de fuente para ver texto/binario/hex). ¿Cuál sería el mejor enfoque para administrar objetos compartidos, por ejemplo fuentes, diálogo de búsqueda, etc.? Pensé que la clase estática con objetos inicializados de forma lenta estaría bien, pero esta podría ser la idea equivocada.

static class ViewerStatic 
{ 
    private static Font monospaceFont; 
    public static Font MonospaceFont 
    { 
     get 
     { 
      if (monospaceFont == null) 
       //TODO read font settings from configuration 
       monospaceFont = new Font(FontFamily.GenericMonospace, 9, FontStyle.Bold); 
      return monospaceFont; 
     } 
    } 

    private static Font sansFont; 
    public static Font SansFont 
    { 
     get 
     { 
      if (sansFont == null) 
       //TODO read font settings from configuration 
       sansFont = new Font(FontFamily.GenericSansSerif, 9, FontStyle.Bold); 
      return sansFont; 
     } 
    } 
} 

Answer 1

Para los elementos que desea crear una vez y luego volver a utilizar, hay dos patrones relevantes: Singleton y Caché. Si va a volver a utilizar el elemento para siempre, Singleton está bien. La memoria asignada a esa instancia nunca se borrará. Si va a volver a utilizar el elemento por un tiempo, pero tal vez esa función no se utilizará durante unos días, le sugiero que use el caché. Entonces la memoria se puede borrar cuando el artículo ya no se usa.

Si está utilizando Singleton, probablemente desee iniciar las fuentes directamente en lugar de utilizar el patrón de inicio diferido. Para mí, las fuentes suenan bastante simples y no es probable que salgan errores. Sin embargo, si el elemento puede fallar durante la construcción (tal vez debido a un archivo de fuente faltante o algo así), el patrón diferido al menos le permite volver a intentarlo la próxima vez. No puede rehacer un inicializador estático más tarde, incluso si falla, sin reiniciar toda la aplicación. ¡Tenga cuidado de limitar esos reintentos!

Finalmente, el nombre de su clase "ViewerStatic" es una preocupación. Hay un antipatrón conocido como el objeto "Dios". Yo lo llamo el "cubo". Si lo creas, las cosas vendrán. Pronto encontrarás todo tipo de cosas arrojadas al cubo. Su clase ViewerStatic se convertirá en enorme. Sería mejor tener una clase llamada "FontFlyWeights" y luego otra llamada "ConstantStrings" o "SystemDialogFactory" ... etc.

Answer 2

Me parece bien, pero ¿es realmente necesario? El enfoque simple sería crear nuevas fuentes y cuadros de diálogo cuando los necesite, luego desecharlos si es necesario y dejar que el recolector de basura los limpie.

¿Ha medido para ver si el enfoque simple tiene un costo notable que hace que valga la pena agregar la complejidad del almacenamiento en caché de objetos compartidos?