Паттерны проектирования

Наследование — «белый ящик»: подкласс опирается на внутреннее устройство суперкласса, поэтому изменение сверху может незаметно его сломать (проблема хрупкого базового класса), а связь фиксируется на компиляции. Композиция — «чёрный ящик»: объект держит сотрудника и делегирует через его интерфейс, поэтому поведение подменяется в рантайме, заглушается в тесте и свободно сочетается. Наследование оставьте для настоящего «является» над стабильным базовым классом.

Создающий паттерн singleton гарантирует, что у класса ровно один экземпляр, и даёт глобальную точку доступа к нему: private конструктор блокирует внешний new, а static поле с аксессором отдают этот единственный экземпляр. Сделать его потокобезопасным без гонок можно через enum (JVM сериализует его инициализацию), вложенный static-holder класс (ленивый, загружается при первом доступе) или double-checked locking на volatile поле.

Создающий паттерн builder конструирует сложный объект шаг за шагом через текучий API — цепочку setter-подобных вызовов, завершаемую build(), — вместо одного огромного конструктора. Он устраняет телескопические конструкторы, где перегрузки с длинными списками одинаковых по типу параметров нечитаемы. К нему обращаются, когда у объекта много необязательных параметров или для неизменяемого объекта: builder собирает поля, затем build() отдаёт результат.

Создающий паттерн factory делегирует создание объекта выделенному методу или подклассу, который возвращает интерфейс или абстрактный тип, вместо вызова клиентом new на конкретном классе. Клиент просит у фабрики абстрактный тип и не знает, какую реализацию получит, поэтому замена или добавление реализаций затрагивает одно место. Он также централизует логику конструирования в этом одном методе.

Дайте DiscountRule ровно один абстрактный метод — long apply(long amountCents), — тогда стратегией становится любая лямбда или ссылка на метод. Checkout принимает правило в конструкторе, держит его в final поле и делегирует: total() возвращает Math.max(0, rule.apply(amountCents)). Новое правило — просто новая лямбда в месте вызова, и Checkout не меняется.

Внедрение зависимостей поставляет коллабораторов объекта снаружи — через его конструктор или setter — вместо того чтобы объект сам создавал их через new. Это инвертирует управление: объект больше не решает, какую конкретную зависимость создать, поэтому зависит от абстракций, а внешний сборщик (часто Spring) связывает граф. Выигрыш — более слабая связанность и лёгкое тестирование: вы внедряете mock и меняете реализации без правки потребителя.

Паттерн проектирования — это переиспользуемое именованное решение повторяющейся проблемы проектирования: проверенный шаблон, который адаптируют под свой код, а не готовая библиотека. Банда четырёх делит их на создающие паттерны (создание объектов, напр. singleton, factory), структурные паттерны (как объекты компонуются, напр. adapter, decorator) и поведенческие паттерны (как объекты взаимодействуют и делят ответственность, напр. observer, strategy).

Декоратор оборачивает объект в другой объект того же интерфейса, добавляет поведение и делегирует остальное тому, кого держит, — поэтому возможности накапливаются в рантайме, а не плодят подкласс на каждую комбинацию. java.io построен так: в new BufferedReader(new InputStreamReader(System.in)) каждая обёртка хранит обёрнутый поток полем и переадресует ему read(), и ступени сочетаются в любом порядке.

Субъект держит список зарегистрированных слушателей и проталкивает событие каждому при изменении своего состояния, поэтому знает только интерфейс слушателя, но не конкретные классы, а наблюдателей можно добавлять и убирать в рантайме. addActionListener из Swing, PropertyChangeSupport и ApplicationListener из Spring устроены так же; субъект держит наблюдателей композицией, а старый класс java.util.Observable объявлен устаревшим в Java 9 за навязанное наследование.

Метод базового класса закрепляет скелет алгоритма — порядок шагов — и делегирует изменяемые шаги abstract или переопределяемым хукам, которые заполняет подкласс; скелет обычно final, чтобы никто не переставил шаги. Классический пример — HttpServlet.service(), раздающий вызовы в doGet: базовый класс владеет неизменным ходом и вызывает вниз, а подкласс поставляет детали.

Factory Method — это один переопределяемый метод, создающий один продукт: конкретный класс выбирает подкласс создателя, поэтому вариация идёт через наследование и фиксируется при выборе подкласса. Abstract Factory — объект с несколькими методами создания, выпускающий целое семейство взаимно согласованных продуктов; клиент держит его композицией, поэтому всё семейство подменяется в рантайме.