Какие знаешь паттерны проектирования?

Слушай, а вот эти ваши паттерны проектирования — это ж, блядь, как готовые рецепты для программиста, понимаешь? Не надо каждый раз изобретать велосипед, когда можно взять проверенную схему и не накосячить. Это как кулинарная книга для кода: хочешь гибкости — открывай одну страницу, хочешь чтобы всё не развалилось — другую.

Ну, вот смотри, на какие три банды они делятся:

1. Порождающие (Creational)

Их задача — рожать объекты правильным образом, чтобы не получилось как в том анекдоте: «создал сто экземпляров, а они все в одной памяти шалят».

• Singleton (Одиночка): Это когда на весь проект должен быть один-единственный экземпляр класса. Например, логгер, который везде один и тот же. Сделал его — и не надо по десять раз инициализировать, блядь.

  public sealed class Logger
  {
      private static readonly Lazy<Logger> _instance = new Lazy<Logger>(() => new Logger());
      public static Logger Instance => _instance.Value;
      private Logger() { } // Спрятал конструктор, чтобы левые люди не плодили
      public void Log(string message) => Console.WriteLine($"[{DateTime.Now}] {message}");
  }
  // Используется просто: Logger.Instance.Log("Приложение стартануло");

  Главное — не злоупотреблять, а то получится глобальная помойка, в которую все скидывают свои зависимости. Это пиздец как некрасиво.

• Factory Method (Фабричный метод) и Abstract Factory (Абстрактная фабрика): Первый — это когда ты делегируешь создание объекта наследникам, а второй — когда нужно целое семейство связанных объектов собрать, не вдаваясь в подробности, кто там конкретно создаётся. Чистая магия, ёпта.

2. Структурные (Structural)

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

• Adapter (Адаптер): Представь, у тебя есть новая крутая система, а подключать надо старую библиотеку, которая говорит на другом языке. Берёшь адаптер — и вуаля, они друг друга понимают. Как переходник с USB-C на старый разъём.
• Composite (Компоновщик): Позволяет работать с группой объектов так, будто это один объект. Дерево файловой системы, интерфейс из кучи кнопок и панелей — везде он.
• Decorator (Декоратор): Хочешь добавить функциональность объекту, но наследование — это слишком жирно и негибко? Оберни его в декоратор! Как лук в бургере: добавил слой — получил новый вкус, не переделывая всю котлету.

3. Поведенческие (Behavioral)

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

• Observer (Наблюдатель): Классика! Один объект (издатель) кричит: «У меня данные изменились!», а куча других (подписчиков) тут же реагирует. В C# это нативные события (event), ими и пользуйся.

• Strategy (Стратегия): Моя любимая, блядь. Суть: выносишь алгоритм в отдельный класс и подсовываешь его основному объекту. Хочешь быструю сортировку — вот тебе одна стратегия, хочешь стабильную — вот другая. Меняешь на лету, как перчатки.

  public interface ISortStrategy<T> { void Sort(List<T> list); }
  public class QuickSortStrategy<T> : ISortStrategy<T> { /* ... */ }
  public class MergeSortStrategy<T> : ISortStrategy<T> { /* ... */ }
  
  public class Sorter<T>
  {
      private ISortStrategy<T> _strategy;
      public void SetStrategy(ISortStrategy<T> strategy) => _strategy = strategy;
      public void ExecuteSort(List<T> list) => _strategy?.Sort(list);
  }

  Гибкость — просто овердохуичная.

• Command (Команда): Заворачиваешь действие в объект. Зачем? А чтобы это действие можно было поставить в очередь, отложить на потом, отменить или записать в лог. Очень удобно для реализации всяких «Отменить/Повторить» в редакторах.

Короче, учи эти паттерны. Не чтобы везде их пихать, а чтобы понимать, каким инструментом какую проблему выебывать. Иначе будешь писать монолитный говнокод, который потом и сам не разберёшь.