La regla de oro para dar nombre a clases contenedoras

Question

me encuentro la creación de un número significativo de clases de envoltura, puramente porque quiero burlarse el comportamiento de

• Las clases que no se prestan bien al modelo de aislamiento RhinoMocks (por ejemplo, como DirectoryInfo o WindowsIdentity)
• métodos de la API nativa Win (normalmente recoger todos los métodos que necesito en una sola clase y envolver las llamadas nativas como un método de clase)

entonces me encuentro añadiendo el clase eso está envuelto con una 'W' (para indicar que es un envoltorio) y así termino con DirectoryInfoW (a diferencia de DirectoryInfoWrapper que parece bastante prolijo). Del mismo modo, termino con métodos nativos envueltos llamados NativeMethods.DuplicateTokenW.

¿Cuál sería una buena regla general a seguir al nombrar las clases de contenedor?

Answer 1

Las convenciones de nomenclatura son lo que funcione para el equipo con el que está trabajando. Mientras todos estén de acuerdo con una convención en particular, entonces está bien.

Tiendo a preferir la versión más detallada, es decir, DirectoryInfoWrapper, en lugar de tener una sola letra que no explica nada a nadie que no esté familiarizado con el código. Pero solo soy yo.

Answer 2

Estoy de acuerdo con aberrant80, si todos están de acuerdo con la convención que está utilizando, entonces funcionará.

Personalmente, prefiero usar nombres que sean más cortos y descriptivos para el propósito de la clase. Al menos en el nivel de interfaz. Si está utilizando un marco simulado, entonces IDirectory o IDirectoryInfo sería un conjunto decente de nombres, mientras que DirectoryInfoW o DirectoryInfoWrapper sería un implementador de interfaz.

Un mejor ejemplo podría estar envolviendo una HttpRequest; defina una solicitud de IR para indicar 'esto es lo que es importante para mi aplicación', luego Request, HttpRequestWrapper, Request, etc. serían implementadores.

Por lo tanto, para resumir, intente utilizar nombres de interfaz descriptivos y no excesivamente detallados.

Answer 3

Así como una nota al margen, he encontrado una manera más estético (bueno, a mí) de envolver método nativo llama:

public class NativeMethods 
{ 
     // made virtual so that it can be mocked - I don't really want 
     // an interface for this class! 
     public virtual bool RevertToSelf() 
     { 
      return WinApi.RevertToSelf(); 
     } 

     ... 

     private static class WinApi 
     { 
      [DllImport("advapi32.dll")] 
      public static extern bool RevertToSelf(); 

      ... 
     } 
} 

es decir, evitar la colisión de nombres mediante la encapsulación de método nativo llama en una clase anidada privada .

Sin embargo, no es una 'buena' solución al problema de nomenclatura de la clase contenedora, probablemente seguiría con la sugerencia de aberrant80 y llamaría explícitamente a mis envoltorios de envoltorios.

Answer 4

Si usa C++, puede usar espacios de nombres y luego reutilizar el mismo nombre de clase. Por ejemplo:

namespace WrapperNamespace 
{ 
    class MyClass {...}; 
} 

namespace InternalNamespace 
{ 
    class MyClass {...}; 
}