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

Чтоб не перегружать потребителя данного кода информацией о многочисленных классах, в качестве хорошей практики, принято использовать паттерн Фасад.

Предлагается некая вариация данного паттерна:

Пусть все классы в проекте будут internal , вся логика, которая должна быть доступна внешнему миру — объявляется в interface.

Но как внешнему коду достучаться до реальной реализации контрактов, если они видимы только в пределах своей сборки? Пусть некий главный фасадный класс с помощью IoC контейнера выполнит связывание интерфейсов с реализациями. И тогда внешний код, запрашивая интерфейс, получит реализацию.

Выглядит это следующим образом:

Более того, связывание можно настраивать, если требуется альтернативная реализация (см. паттерн Стратегия), подобно тому как принято настраивать Js-модули.

Если вам понравилась статья, помогите, пожалуйста с распространением этого материала в Сети.

Подпишитесь на наши новости

Добавить комментарий

Ваш e-mail не будет опубликован.

Этот сайт использует Akismet для борьбы со спамом. Узнайте как обрабатываются ваши данные комментариев.