Правило большого пальца для имен классов обертки

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

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

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

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

Ответы

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 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 и явно вызывал обертки оберток.

Ответ 4

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

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

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