Я рекомендую придерживаться хороших принципов проектирования и структуры при разработке приложений.
В процессе разработки мы добавляем новые функции в наши приложения: это может быть запрос функции от вашего клиента или улучшения, которые вы предложили. Несмотря ни на что, эти предстоящие изменения также изменят уже заданную кодовую базу. Когда вносятся изменения, мы хотим, чтобы это было как можно проще.
В этом посте я собираюсь показать вам пример того, как вы можете использовать шаблон декоратора с мощным контейнером IoC Autofac в сценариях, где вы хотите расширить функциональность существующей функции.
Допустим, вы собираетесь создать сервис, который обслуживает продукты. Мы будем называть эту службу IProductRepository и для простоты используем только один метод, называемый GetById. Это могло бы выглядеть примерно так с подключенной к нему реализацией:
Обычно вы регистрируете свою конкретную реализацию XmlProductRepository как IProductRepository со следующей строкой кода для поддержки принципа инверсии зависимостей:
Допустим, вам через какое-то время потребуется регистрация при получении продуктов. Как этого добиться?
Заманчиво просто изменить реализацию XmlProductRepository, внедрив такую службу ведения журнала:
Но это нарушает принцип открытого / закрытого. Принцип гласит, что вам не разрешено изменять классы, но вы можете их расширять. Здесь действительно пригодится паттерн-декоратор.
Вместо того, чтобы загромождать исходную реализацию, вы расширяете ее, добавляя прокси-сервер ведения журнала и регистрируя его как его декоратор.
Однако вам придется изменить одну строку кода, и это регистрация исходной реализации. Теперь это должна быть именованная регистрация, чтобы мы могли ссылаться на нее при регистрации нашего декоратора:
А потом подключите и зарегистрируйте декоратор:
Ключ, который мы используем здесь для ссылки на реализацию, - это productRepository. Когда у вас есть этот код, первым классом, который будет вызываться, когда вы вводите свой IProductRepository, будет LoggingProductRepositoryProxy, и, поскольку мы внедрили для него внутреннюю реализацию, он будет просто работать как прокси (стиль русской куклы) после открытия / закрытия принцип.
Допустим, ваш XmlProductRepository работает медленно, и вам нужно на некоторое время кэшировать свои продукты. Как бы вы это реализовали? Довольно легко просто добавить еще один декоратор поверх вашей реализации ведения журнала:
Довольно гибкий!
Шаблон декоратора действительно эффективен, когда дело касается поддержки сквозных задач в приложениях.
Вы нашли этот пост полезным? Ты знаешь что делать! 👏
