Эмпирического правила для именования оболочки классов

Question

Я считаю себя созданием значительного числа классов-оболочек, только потому, что я хочу, чтобы дразнить из поведения

• классов, которые не поддаются хорошо модель изоляции RhinoMocks (например, как DirectoryInfo или WindowsIdentity)
• методы API Native Win (я обычно собирать все методы, которые мне нужны в один класс и завернуть родные вызовы как метод класса)

я тогда окажусь добавляя класс который обернут «W» (чтобы указать, что это обертка), и поэтому я заканчиваю DirectoryInfoW (в отличие от DirectoryInfoWrapper, который кажется довольно многословным). Точно так же в итоге я обернул собственные методы, называемые NativeMethods.DuplicateTokenW.

Что было бы хорошим эмпирическим правилом для обозначения классов обертки?

Answer 1

Соглашения об именах - это все, что работает для команды, с которой вы работаете. Пока все в порядке с определенным соглашением, тогда все в порядке.

Я предпочитаю более подробный вариант, т. Е. DirectoryInfoWrapper, вместо того, чтобы иметь единственную букву, которая ничего не объясняет никому, кто не знаком с кодом. Но это только я.

Answer 2

Я соглашусь с аберрантом80, если все согласятся с конвенцией, которую вы используете, тогда это сработает.

Я лично предпочитаю использовать имена, которые короче и описательны для целей класса. По крайней мере, на уровне интерфейса. Если вы используете фальшивую фреймворк, то IDirectory или IDirectoryInfo будут достойным набором имен, в то время как DirectoryInfoW или DirectoryInfoWrapper будут разработчиками интерфейса.

Лучшим примером может быть упаковка HttpRequest; определите IRequest, чтобы указать «это то, что важно для моего приложения», а затем Request, HttpRequestWrapper, Request и т. д. будут исполнителями.

Итак, чтобы суммировать, попробуйте использовать описательные, не слишком многословные имена интерфейсов.

Answer 3

Так же, как примечание стороны, я нашел более эстетично (ну, для меня) способа упаковки нативного метода вызывает:

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(); 

      ... 
     } 
} 

т.е. избежать столкновения имени инкапсулируя нативный метод вызывает в частном вложенном классе ,

Нет «хорошего» решения проблемы с именованием класса оболочки, хотя, вероятно, я бы пошел с предложением aberrant80 и явным образом назвал свои обертки оберток.

Answer 4

Если вы используете C++, вы можете использовать пространства имен, а затем просто повторно использовать одно и то же имя класса. Например:

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

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