Использование шаблона Adapter/Facade для прогнозирования несовместимых интерфейсов и сложности?

Question

Шаблон адаптера упоминается в Википедии для устранения несовместимости между ожидаемым интерфейсом и фактическим интерфейсом.

Фасад, как говорят, скрывает сложные реализации и представляет собой упрощенный API.

Однако, будут ли эти шаблоны использоваться даже при отсутствии этих проблем? Ака, преждевременно использовать эти шаблоны в ожидании будущей несовместимости и сложности?

Я столкнулся с кодом, в котором был реализован класс-оболочка с точной копией интерфейса внутреннего класса - он имел все общедоступные методы оригинала с точно такими же параметрами. Класс-оболочка и внутренний класс также были определены в той же сборке.

Как так:

public class ClassifierImplementation 
{ 
    private Classifier classifier_; 
    public Wrapper() { classifier_ = new Classifier(); } 

    public int[] Classify(double[] values, int seed) 
    { 
     return classifier_.Classify(values, seed); 
    } 

    // And other more public methods 
} 

Что бы Обоснованием такой реализации?

Answer 1

Я пойду с шаблоном анализа 1 в то время -

• Adapter Pattern Пример Классификатор приведенный выше выглядит адаптер, как он приспосабливается (идет по классическому определению объектного адаптера) от ClassifierImplementation до Classifier - но это не совсем адаптируется от одного типа к другому, поскольку вы упомянули, что методы одинаковы. Следовательно, если все одинаково - зачем приспосабливаться !!

• Фасад шаблон - Его не фасад, как фасад выполнен, чтобы упростить интерфейс (методы в данном случае), тогда как в этом случае метода определение/метод одинаково для ClassifierImplementation и классификатора. ClassifierImplementation кажется более обертки (как вы упомянули) над классификатором, который приносит мне к моему следующему пункту -

• Proxy Pattern - Это выглядит как экземпляр прокси-шаблон, в котором ClassifierImplementation пытается контролировать доступ к экземпляр Классификатора, который он держит. Таким образом, реализация классификатора может изменять параметры входящего запроса или исходящие возвращаемые значения в соответствии с его потребностями, а определения методов не изменяются.

Наконец, все сказано и сделано, класс ClassifierImplementation должен быть переименован в нечто более значимое (например, ClassifierProxy), поскольку она не удлинении или реализации ничего. Текущее имя создает путаницу и уменьшает читаемость.

Примечание. КлассификаторImplementation может реализовать тот же интерфейс, который реализует Classifier, но тогда он будет скорее декоратором, чем прокси.

Answer 2

Я столкнулся с кодом, в котором класс оболочки был реализован с точной копией интерфейса внутреннего класса - он имел все общедоступные методы оригинала с точно такими же параметрами. Класс-оболочка и внутренний класс также были определены в той же сборке.

Каково было бы обоснование такой реализации?

Одна из причин заключается в создании абстракции, которую может реализовать класс-оболочка.

Примером этого является класс HttpContext в ASP.NET. Первоначальной реализацией ASP.NET был класс HttpContext, который имел очень большой и сложный интерфейс.

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

Таким образом, в более поздней версии .NET был создан абстрактный класс HttpContextBase с таким же интерфейсом, как и HttpContext. Кроме того, он поставляется с конкретной реализацией под названием HttpContextWrapper, которая приняла пример HttpContext в качестве параметра конструктора.

Теперь тестирование намного проще, потому что для проверки кода требуется только зависимость от HttpContextBase. Легко использовать насмешливую библиотеку для определения только нескольких свойств за раз, чтобы удовлетворить логику тестируемого кода.

Живое приложение, как правило, имеют HttpContextWrapper впрыскивается в него вместо этого, и так как он имеет точно такой же интерфейс, как HttpContext он делает то же самое, как не-mockable HttpContext класса в производстве.

Наличие такого же интерфейса означает, что для проверки существующего кода необходимо изменить только переменную или ссылку на параметр от HttpContext до HttpContextBase, и ни один другой код не требуется изменять.