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

1) Пример «монолита» — что чаще всего встречается
(псевдокод / C#-стиль для ясности):

class BookingManager
{
// создаёт бронь, проверяет доступность, рассчитывает цену,
// проводит платёж, сохраняет в БД, отправляет уведомления, логирует, обрабатывает отмены и т.п.
public BookingResult CreateBooking$BookingRequestreq$ {
// 1. Валидация входных данных
if $!Validate(req)$ throw new ValidationException;

// 2. Проверка доступности номеров
if $!CheckAvailability(req.RoomType,req.Dates)$ return fail;
// 3. Расчёт цены с учётом скидок
var price = CalculatePrice$req$;
// 4. Платёж
var paymentResult = ProcessPayment$req.PaymentDetails,price$;
if $!paymentResult.Success$ return fail;
// 5. Сохранение записи в БД
SaveBookingToDb$...$;
// 6. Отправка уведомления клиенту
SendEmail$...$;
SendSms$...$;
// 7. Логирование/метрики
Log$...$;
return success;
}
// плюс методы CancelBooking, Refund, GetBookings, ImportRatePlan, etc.

}

Какие проблемы здесь:

один класс делает всё: доступность, расчёт цены, оплата, persist, уведомления, валидация, логирование, интеграции — нарушение SRP;чтобы добавить новый способ оплаты или уведомления, придётся менять BookingManager — нарушение OCP;интерфейс/класс, который обязан реализовать много методов, которые конкретному клиенту не нужны — нарушение ISP $впримереэтопроявляется,еслимывынесеминтерфейсIBookingManagerскучейметодов$;если наследовать BookingManager для особой логики и ломать контракт — потенциальное нарушение LSP;BookingManager напрямую использует реализацию БД/платежного шлюза — нарушение DIP $зависитотдеталей$.

2) Как рефакторить — целевые сущности и интерфейсы
Основная идея: разбить ответственность, ввести абстракции $интерфейсы$, внедрять зависимости $DI$ и расширять поведение через стратегии/плагины/цепочки.

Предлагаемая структура $строгоеразделениеролей$:

Domain model:

Booking, Customer, Room, Payment, Price, BookingRequest, BookingResult

Core services / интерфейсы:

IBookingService — высокий уровень для создания/отмены броней $координатор$.IAvailabilityChecker — проверка доступности номеров.IPricingStrategy $илиIPricingService$ — расчёт цены $поддерживаетплагины:скидки,налоги$.IPaymentProcessor — обработка платежей $интерфейс,разныереализациидляStripe,PayPal,test$.IBookingRepository — абстракция доступа к данным $Save,Get,Query$.INotificationSender $илинесколько:IEmailSender,ISmsSender$ — отправка уведомлений.IBookingValidator $илинаборвалидаторов$ — валидация запроса.ILogger / IEventPublisher — логирование и публикация доменных событий.

Patterns:

Strategy: для расчёта цены, для оплаты, для уведомлений.Chain of Responsibility / Composite: для набора валидаторов или правил ценообразования.Unit of Work / Transaction + Domain Events: уведомления и интеграции после успешной записи.

Пример интерфейсов $псевдокод$:

interface IAvailabilityChecker { bool IsAvailable$RoomType,DateRange$; }
interface IPricingService { Money Calculate$BookingRequest$; }
interface IPaymentProcessor { PaymentResult Charge$PaymentDetails,Money$; }
interface IBookingRepository { void Save$Booking$; Booking Get$id$; }
interface INotificationSender { void Send$BookingNotification$; }
interface IBookingValidator { ValidationResult Validate$BookingRequest$; }
interface IBookingService { BookingResult CreateBooking$BookingRequest$; }

Теперь IBookingService реализует координацию, не детали:

class BookingService : IBookingService
{
private readonly IAvailabilityChecker availability;
private readonly IPricingService pricing;
private readonly IPaymentProcessor payment;
private readonly IBookingRepository repo;
private readonly IEnumerable notifiers;
private readonly IBookingValidator validator;
private readonly ILogger log;

public BookingResult CreateBooking$BookingRequestreq$ {
var v = validator.Validate$req$;
if $!v.Ok$ return fail;
if $!availability.IsAvailable(req.RoomType,req.Dates)$ return fail;
var price = pricing.Calculate$req$;
var paymentResult = payment.Charge$req.Payment,price$;
if $!paymentResult.Success$ return fail;
var booking = new Booking$...$;
repo.Save$booking$;
// публикация события/уведомления после успешной транзакции
foreach $varninnotifiers$ n.Send$newBookingCreated(booking)$;
log.Info$...$;
return success;
}

}

3) Как SOLID принципы применяются и какие проблемы решают

SRP $SingleResponsibilityPrinciple$

Проблема в монолите: BookingManager отвечает за 8+ разных вещей.Рефакторинг: выделить отдельные классы для каждой ответственности: AvailabilityChecker, PricingService, PaymentProcessor, Repository, NotificationSender, Validator.Результат: проще менять/тестировать/реиспользовать каждую часть.

OCP $Open/ClosedPrinciple$

Проблема в монолите: чтобы добавить новый способ оплаты или новую акцию, надо править BookingManager.Рефакторинг: ввести абстракции $IPaymentProcessor,IPricingService,INotificationSender$ и регистрировать новые реализации. Добавление новых стратегий не требует изменения BookingService.Результат: расширяемость через новые реализации, минимальные изменения уже работающего кода.

LSP $LiskovSubstitutionPrinciple$

Потенциальная проблема: если создают подкласс BookingManagerSpecial и меняют семантику CreateBooking $например,бросаютexceptionsтамгдебазовыйвозвращалкод$, то клиенты ломаются.Рефакторинг: проектировать абстракции с ясными контрактами $чтовозвращается,какиеисключениядопустимы$. Проверяем, что любые реализации интерфейса соблюдают контракт: same input -> compatible output/side-effects.Результат: можно безопасно заменять реализации $напримертестовыйплатежныйпроцессорвместобоевого$.

ISP $InterfaceSegregationPrinciple$

Проблема: один «толстый» интерфейс IBookingManager с множеством методов заставляет клиентов реализовывать/зависеть от ненужных методов.Рефакторинг: разбить интерфейсы на маленькие: IBookingService, IBookingRepository, IPaymentProcessor, IAvailabilityChecker, INotificationSender. Клиентам даём только те интерфейсы, которые им нужны.Результат: уменьшение связности и более понятные контрактные границы.

DIP $DependencyInversionPrinciple$

Проблема: BookingManager напрямую создаёт/использует конкретные классы $SqlRepository,StripeClient,SmtpClient$.Рефакторинг: BookingService зависит от абстракций $интерфейсов$. Конкретные реализации внедряются извне через DI-контейнер или фабрики.Результат: проще тестировать $моки$, менять реализации, конфигурировать систему.

4) Небольшие практические рекомендации по рефакторингу $инкрементально$

Шаг 1: Написать тесты на текущую логику CreateBooking $чтобыповедениесохранено$.Шаг 2: Выделить IAvailabilityChecker и перенести логику проверки доступности; внедрить в BookingManager $иливременныйфасад$ через конструктор. Запустить тесты.Шаг 3: Выделить IPricingService $первоначальноимплементациякопируетстаруюлогику$. Тесты.Шаг 4: Выделить IPaymentProcessor $внедрятьтестовыйstub/моквовремятестов$.Шаг 5: Выделить IBookingRepository $persist$. Ввести транзакцию/UnitOfWork, чтобы уведомления отправлялись только после успешной коммита.Шаг 6: Создать BookingService как координирующий класс $high-level$, удалить логику из монолитного BookingManager. Монолит можно оставить как адаптер к новому BookingService, чтобы не ломать внешний API, и постепенно удалить.Шаг 7: Вынести уведомления и логирование, подключать через события/observer.

5) Примеры шаблонов/вариантов

Pricing: реализовать как цепочку правил $ChainofResponsibility$ или набор стратегий, которые комбинируются.Payment: Strategy для разных провайдеров + Factory для выбора по метаданным.Validation: набор IValidator реализует проверку; BookingService просто прогоняет все валидаторы.Events: после сохранения публикуем BookingCreated event, подписчики $нотсифай,аналитика$ реагируют.

6) Контроль ошибок и атомарность

Используйте транзакции/UnitOfWork: сначала сохраняем бронь, затем отправляем уведомления только после подтверждённого коммита.Для взаимодействия с внешними сервисами $платёж,уведомления$ применяйте стратегию компенсации/ре.try $илиsagaдляраспределённыхпроцессов$.

7) Маппинг нарушений → рефакторинг $кратко$

SRP: выделить Availability, Pricing, Payment, Repo, Notification, Validation.OCP: ввести IPricingService / IPaymentProcessor / INotificationSender — добавляем реализации без изменения BookingService.LSP: чёткие контракты интерфейсов, предусмотреть поведение в пограничных сценариях $невозвращатьnull,использоватьResult-объекты$.ISP: дробить большие интерфейсы на специализированные.DIP: внедрять зависимости через интерфейсы, использовать DI-контейнер.

8) Заключение — что вы получаете

Меньше «больших классов» — легче понимать и тестировать.Локализация изменений: добавить платежный провайдер или акцию — минимальные изменения.Проще писать unit-тесты $можномокатьIPaymentProcessor,IBookingRepository$.Система становится более гибкой и готовой к масштабированию.

Если хотите, могу:

предложить конкретную структуру файлов/пакетов для проекта;привести полный пример кода (на C# / Java / TypeScript) с интерфейсами и базовыми реализациями;показать, как организовать миграцию существующего монолита пошагово с примерами тестов.