Как и зачем использовать Template Method в C#

Template Method (он же «Шаблонный метод») — это паттерн проектирования, который определяет скелет алгоритма в методе, оставляя определенные шаги подклассам. Проще говоря, есть базовый алгоритм, но мы можно менять детали, переопределяя части этого алгоритма в наследниках.

Классический пример — процесс заказа товара в интернет-магазине. Независимо от того, какой у вас магазин, шаги примерно одинаковые: проверка наличия товара, оплата, упаковка и доставка. Но в зависимости от специфики магазина, эти шаги могут отличаться в деталях.

Template Method позволяет создать базовую структуру этих шагов и менять конкретные реализации без изменения самой структуры. В этой статье мы рассмотрим как реализовать этот паттерн на C#.

Основная структура паттерна

Для начала — нарисуем на пальцах. Вот есть базовый класс OrderProcess, и он содержит метод ProcessOrder(). В этом методе прописаны основные шаги — шаги шаблона. Эти шаги могут быть представлены как методы, которые подклассы могут переопределять, изменяя поведение.

public abstract class OrderProcess {     // Шаблонный метод, определяющий основной алгоритм.     public void ProcessOrder()     {         SelectProduct();         MakePayment();         if (CustomerWantsReceipt()) // Перехватчик хука — необязательный шаг         {             GenerateReceipt();         }         Package();         Deliver();     }      // Шаги, которые могут быть переопределены в подклассах.     protected abstract void SelectProduct();     protected abstract void MakePayment();     protected abstract void Package();     protected abstract void Deliver();      // "Хук" — метод с базовой реализацией, который можно переопределить.     protected virtual bool CustomerWantsReceipt()      {         return true; // По умолчанию считаем, что клиент хочет чек     }      // Этот метод остается фиксированным — он не изменяется.     private void GenerateReceipt()     {         Console.WriteLine("Чек сгенерирован.");     } }

Теперь создадим две реализации процесса заказа — OnlineOrder и StoreOrder. OnlineOrder будет представлять покупку в онлайн-магазине, а StoreOrder — обычный заказ в розничном магазине.

Пример кода для OnlineOrder:

public class OnlineOrder : OrderProcess {     protected override void SelectProduct()     {         Console.WriteLine("Выбран товар в интернет-магазине.");     }      protected override void MakePayment()     {         Console.WriteLine("Оплата произведена онлайн.");     }      protected override void Package()     {         Console.WriteLine("Товар упакован для доставки.");     }      protected override void Deliver()     {         Console.WriteLine("Товар отправлен почтой.");     }      protected override bool CustomerWantsReceipt()     {         return false; // Онлайн-заказчик, предположим, не хочет чека     } }

Пример кода для StoreOrder:

public class StoreOrder : OrderProcess {     protected override void SelectProduct()     {         Console.WriteLine("Выбран товар в магазине.");     }      protected override void MakePayment()     {         Console.WriteLine("Оплата произведена на кассе.");     }      protected override void Package()     {         Console.WriteLine("Товар упакован в пакет.");     }      protected override void Deliver()     {         Console.WriteLine("Товар выдан покупателю.");     } }

Здесь мы сделали вот что:

• Шаблонный метод ProcessOrder — фиксирует общую структуру алгоритма.

• Абстрактные методы SelectProduct, MakePayment, Package, Deliver — определяют шаги, которые должны быть реализованы в подклассах.

• Метод CustomerWantsReceipt — «хук», который позволяет подклассам модифицировать алгоритм, не переопределяя его целиком.

Этот подход позволяет избежать дублирования и повысить гибкость, если вдруг потребуется изменить шаги, добавив новые особенности в подклассах. Например, можно добавить новый подкласс GiftOrder с нестандартной упаковкой подарков.

Пример с подарочным заказом:

public class GiftOrder : OrderProcess {     protected override void SelectProduct()     {         Console.WriteLine("Выбран товар для подарка.");     }      protected override void MakePayment()     {         Console.WriteLine("Оплата подарка произведена.");     }      protected override void Package()     {         Console.WriteLine("Товар упакован как подарок.");     }      protected override void Deliver()     {         Console.WriteLine("Подарок доставлен курьером.");     }      // Переопределяем хук — клиент может выбрать подарочную упаковку.     protected override bool CustomerWantsReceipt()     {         return true; // Допустим, клиент всё-таки хочет чек     } }

Теперь запустим все три реализации. Просто создадим объекты и вызовем ProcessOrder().

class Program {     static void Main()     {         OrderProcess onlineOrder = new OnlineOrder();         onlineOrder.ProcessOrder();          Console.WriteLine();          OrderProcess storeOrder = new StoreOrder();         storeOrder.ProcessOrder();          Console.WriteLine();          OrderProcess giftOrder = new GiftOrder();         giftOrder.ProcessOrder();     } }

Результат:

Выбран товар в интернет-магазине. Оплата произведена онлайн. Товар упакован для доставки. Товар отправлен почтой.  Выбран товар в магазине. Оплата произведена на кассе. Товар упакован в пакет. Чек сгенерирован. Товар выдан покупателю.  Выбран товар для подарка. Оплата подарка произведена. Товар упакован как подарок. Чек сгенерирован. Подарок доставлен курьером.

Интеграция Template Method с другими паттернами

Полезно знать как Template Method может гармонично сосуществовать с другими паттернами

Template Method и Dependency Injection

Когда мы комбинируем Template Method с DI, мы получаем гибкую и тестируемую архитектуру, где зависимости могут легко заменяться без изменения базового алгоритма.

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

public interface ILogger {     void Log(string message); }  public class ConsoleLogger : ILogger {     public void Log(string message)     {         Console.WriteLine($"[ConsoleLogger] {message}");     } }  public abstract class OrderProcess {     private readonly ILogger _logger;      protected OrderProcess(ILogger logger)     {         _logger = logger;     }      public void ProcessOrder()     {         _logger.Log("Начало обработки заказа.");         SelectProduct();         MakePayment();         if (CustomerWantsReceipt())         {             GenerateReceipt();         }         Package();         Deliver();         _logger.Log("Заказ обработан.");     }      protected abstract void SelectProduct();     protected abstract void MakePayment();     protected abstract void Package();     protected abstract void Deliver();      protected virtual bool CustomerWantsReceipt()     {         return true;     }      private void GenerateReceipt()     {         Console.WriteLine("Чек сгенерирован.");     } }

Теперь создадим конкретную реализацию заказа с использованием логгера:

public class OnlineOrder : OrderProcess {     public OnlineOrder(ILogger logger) : base(logger) { }      protected override void SelectProduct()     {         Console.WriteLine("Выбран товар в интернет-магазине.");     }      protected override void MakePayment()     {         Console.WriteLine("Оплата произведена онлайн.");     }      protected override void Package()     {         Console.WriteLine("Товар упакован для доставки.");     }      protected override void Deliver()     {         Console.WriteLine("Товар отправлен почтой.");     }      protected override bool CustomerWantsReceipt()     {         return false;     } }

Использование:

class Program {     static void Main()     {         ILogger logger = new ConsoleLogger();         OrderProcess onlineOrder = new OnlineOrder(logger);         onlineOrder.ProcessOrder();     } } 

Результат:

[ConsoleLogger] Начало обработки заказа. Выбран товар в интернет-магазине. Оплата произведена онлайн. Товар упакован для доставки. Товар отправлен почтой. [ConsoleLogger] Заказ обработан.

Тестирование Template Method

Тестирование паттерна Template Method может показаться сложным из-за зависимости от наследования, но с правильным подходом это вполне выполнимая задача. Рассмотрим, как можно протестировать наш OrderProcess и его подклассы.

С помощью фреймворков для создания мок-объектов, например как как Moq, можно проверять вызовы методов и поведение подклассов.

Пример теста с использованием Moq и xUnit:

using Moq; using Xunit;  public class OnlineOrderTests {     [Fact]     public void ProcessOrder_ShouldExecuteStepsCorrectly()     {         // Arrange         var loggerMock = new Mock();         var onlineOrderMock = new Mock(loggerMock.Object)          {              CallBase = true          };          // Act         onlineOrderMock.Object.ProcessOrder();          // Assert         onlineOrderMock.Verify(o => o.SelectProduct(), Times.Once);         onlineOrderMock.Verify(o => o.MakePayment(), Times.Once);         onlineOrderMock.Verify(o => o.GenerateReceipt(), Times.Never); // Поскольку CustomerWantsReceipt() возвращает false         onlineOrderMock.Verify(o => o.Package(), Times.Once);         onlineOrderMock.Verify(o => o.Deliver(), Times.Once);     } }

В этом примере создаем мок-объект OnlineOrder, который позволяет отслеживать вызовы методов. Мы проверяем, что все необходимые методы вызываются один раз, а метод GenerateReceipt не вызывается, поскольку CustomerWantsReceipt() возвращает false.

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

public class GiftOrderTests {     [Fact]     public void ProcessOrder_ShouldGenerateReceipt()     {         // Arrange         var loggerMock = new Mock();         var giftOrder = new GiftOrder(loggerMock.Object);          // Act         giftOrder.ProcessOrder();          // Assert         Assert.True(giftOrder.CustomerWantsReceipt());         // Дополнительные проверки могут включать использование моков для отслеживания вызовов     } } 

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

Потенциальные подводные камни

Как и любой паттерн, Template Method имеет свои ограничения и может привести к проблемам, если использовать его неправильно.

• Глубокая иерархия наследования: чрезмерное использование Template Method может привести к созданию сложной иерархии классов.

• Сильная связанность: подклассы сильно зависят от базового класса, что может затруднить их изменение или переиспользование в других контекстах.

---

Краткие выводы

• Template Method помогает определить общий алгоритм, оставляя детали подклассам.

• Он отлично подходит для сценариев с повторяющейся общей логикой и изменяющимися шагами.

• Важно избегать чрезмерного использования наследования и помнить о возможных подводных камнях, таких как глубокая иерархия классов.

• Комбинирование с другими паттернами, такими как Dependency Injection или Decorator, в каких то случаях повышает гибкость системы.

До новых встреч!

В заключение порекомендую обратить внимание на открытые уроки курса «C# Developer. Professional»:

28 октября: «Сериализатор данных с использованием Reflection и Generics». Подробнее
12 ноября: «Поведенческие шаблоны проектирования в C#». Подробнее