создание обёртки вокруг сторонней сборки - выгрузка и развязка

Question

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

Мой подход сейчас таков:

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

3. любое использование этого компонента будет осуществляться через интерфейс, например:

   IPop3 pop3 = new AcmeIncePop3Wrapper (); pop3.connect ();

и внутри AcmeIncePop3Wrapper будет:

   public void connect()
   {
         AcmeIncePop3 pop = new AcmeIncePop3();
         pop.connect();
   }

Это хороший подход?

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

Answer 1

Я думаю, у вас хорошая реализация. В основном ваш интерфейс говорит: «Вот как я хочу иметь дело с электронной почтой», и сторонние компоненты могут действовать по-другому, но если вы создаете свои классы-обертки на основе вашего интерфейса, вы сможете использовать любой сторонний компонент в этом интерфейсе.

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

Answer 2

Вы на правильных линиях.

Простое использование интерфейса не решит проблему, так как вы не можете добавить интерфейс к определению к нужному классу, если он находится в сборке стороннего производителя. Вместо этого сделайте одно из двух:

1. создать совершенно новый класс с методы, общие для всех разных сборки, которые вы знаете, и обрабатывать каждая отдельная сборка, которая может существует (дополнительная логика может быть нужно здесь, чтобы справиться с основными различия).

2. создать интерфейс с общими методы и т. д., затем создайте новый класс, который наследует от 3-го класс партии и реализует интерфейс. Сделайте это для каждого класса в новые сборки, которые вам нужно использовать.

Проблема с вариантом 2 заключается в том, что вы не можете расширить sealed class, что, как я ожидаю, будет делать третья сторона. Я рекомендую вариант 1.

Answer 3

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