Какие паттерны проектирования GoF вы используете в работе?

В зависимости от задачи, часто применяю следующие паттерны из каталога GoF:

1. Стратегия (Strategy) Использую для инкапсуляции семейства алгоритмов и обеспечения их взаимозаменяемости. Это устраняет условные операторы и упрощает добавление новых правил.

// Интерфейс стратегии
public interface ISortStrategy
{
    void Sort(List<int> data);
}

// Конкретные стратегии
public class QuickSort : ISortStrategy { /*...*/ }
public class MergeSort : ISortStrategy { /*...*/ }

// Контекст
public class Sorter
{
    private ISortStrategy _strategy;
    public Sorter(ISortStrategy strategy) => _strategy = strategy;
    public void SetStrategy(ISortStrategy strategy) => _strategy = strategy;
    public void ExecuteSort(List<int> data) => _strategy.Sort(data);
}

2. Наблюдатель (Observer) Незаменим для реализации событийных моделей, например, в UI или для оповещения подсистем о изменениях состояния.

// Используем встроенные события .NET
public class OrderService
{
    public event EventHandler<OrderEventArgs> OrderCreated;
    public void CreateOrder(Order order)
    {
        // Логика создания...
        OnOrderCreated(new OrderEventArgs(order));
    }
    protected virtual void OnOrderCreated(OrderEventArgs e) => OrderCreated?.Invoke(this, e);
}
// Подписчик (например, сервис нотификаций) подписывается на событие OrderCreated.

3. Фабричный метод (Factory Method) Применяю, когда логика создания объектов должна быть делегирована подклассам, или когда тип создаваемого объекта зависит от контекста.

public abstract class DocumentCreator
{
    // Фабричный метод
    public abstract IDocument CreateDocument();
    public void OpenDocument()
    {
        var doc = CreateDocument(); // Создание делегировано подклассам
        doc.Open();
    }
}
public class ReportCreator : DocumentCreator
{
    public override IDocument CreateDocument() => new Report();
}

Другие часто используемые паттерны:

• Адаптер (Adapter): Для интеграции классов со несовместимыми интерфейсами (например, работа со сторонними библиотеками).
• Декоратор (Decorator): Для динамического добавления поведения объектам без наследования (например, кэширующие или логирующие декораторы для репозиториев).
• Внедрение зависимости (Dependency Injection): Хотя это не классический GoF-паттерн, он является краеугольным камнем для достижения слабой связанности, часто используя конструкции, похожие на Абстрактную фабрику.

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