Ниже — краткое объяснение принципов SOLID на примере учебного проекта «система управления библиотекой», пример кода, сознательно нарушающий несколько принципов, и последовательность рефакторинга с примером исправленного кода.

Коротко о SOLID $однопредложениенапринцип$

S $SingleResponsibility$ — класс должен иметь одну причину для изменения $однуответственность$.O $Open/Closed$ — сущности открыты для расширения, но закрыты для модификации.L $LiskovSubstitution$ — объекты наследников должны быть взаимозаменяемы с объектами базового типа.I $InterfaceSegregation$ — не заставлять клиентов зависеть от методов, которые они не используют $толстыеинтерфейсыразделять$.D $DependencyInversion$ — высокоуровневые модули не должны зависеть от низкоуровневых; оба — от абстракций.

Проблема проекта «библиотека» в учебном примере: часто одна сущность делает всё — хранит книги, выдает, сохраняет на диск, печатает отчёты. Это ведёт к нарушению SRP, DIP, OCP и иногда LSP/ISP.

1) Пример «плохого» кода $нарушаеткакминимумSRPиDIP,плюсLSP$:
(псевдо-C#; упрощённо)

class Book
{
public string Id;
public string Title;
public virtual void Borrow$Useruser$ {
// логика выдачи книги
}
}

class ReferenceBook : Book
{
// нарушает LSP — наследник бросает исключение вместо корректного поведения
public override void Borrow$Useruser$ {
throw new InvalidOperationException("Reference books cannot be borrowed");
}
}

class LibraryManager
{
private List books = new List;

public void AddBook$Bookb$ => books.Add$b$;
public void BorrowBook$stringid,Useruser$ {
var book = books.FirstOrDefault(b => b.Id == id);
if $book==null$ throw new Exception$"Notfound"$;
book.Borrow$user$; // бизнес-логика
// сохранение $низкоуровневаязависимостьотфайловойсистемы$ File.WriteAllText$"books.json",JsonConvert.SerializeObject(books)$;
// вывод отчёта $прямойвызовконсоли$ Console.WriteLine$"Report:totalbooks="+books.Count$;
}

}

Почему это плохо

LibraryManager отвечает за бизнес-логику, за хранение и за презентацию — нарушен SRP.LibraryManager жёстко зависит от File и Console — нарушен DIP $иусложненотестирование$.ReferenceBook переопределяет Borrow, бросая исключение — нарушает LSP: код, работающий с Book, при подстановке ReferenceBook ломается.

2) Цель рефакторинга

Разделить ответственности $SRP$.Ввести абстракции $интерфейсы$ и внедрение зависимостей $DIP$.Убрать наследование, которое ломает LSP, или пересмотреть модель так, чтобы поведение не нарушало заменяемость.Разделить интерфейсы на узкие $ISP$.Обеспечить возможность расширения $OCP$.

3) Шаги рефакторинга $пошагово$ и пример исправленного кода

Шаг 1 — выделить репозиторий для хранения книг $SRP,DIP$

Сделать интерфейс IBookRepository и реализацию FileBookRepository.

interface IBookRepository
{
void Add$Bookbook$;
Book GetById$stringid$;
IEnumerable GetAll;
void SaveChanges;
}

class FileBookRepository : IBookRepository
{
private readonly string path = "books.json";
private List books = LoadFromFile;

public void Add$Bookbook$ { books.Add$book$; }
public Book GetById$stringid$ => books.FirstOrDefault(b => b.Id == id);
public IEnumerable<Book> GetAll => books;
public void SaveChanges => File.WriteAllText$path,JsonConvert.SerializeObject(books)$;
// LoadFromFile — чтение/десериализация

}

Шаг 2 — отделить генерацию отчётов/презентацию $SRP,DIP,OCP$

Ввести IReportGenerator; для консоли — ConsoleReportGenerator; позже можно добавлять HtmlReportGenerator без изменения существующего кода.

interface IReportGenerator
{
void GenerateLibraryReport$IEnumerable<Book>books$;
}

class ConsoleReportGenerator : IReportGenerator
{
public void GenerateLibraryReport$IEnumerable<Book>books$ {
Console.WriteLine("Total books: " + books.Count());
}
}

Шаг 3 — убрать ломающее LSP поведение для ReferenceBook $ввестимелкиеинтерфейсы$ $LSP,ISP$ Вместо того, чтобы заставлять все Book поддерживать Borrow, вводим интерфейс IBorrowable — только книги, которые можно выдавать, его реализуют.

interface IBorrowable
{
void Borrow$Useruser$;
bool IsAvailable { get; }
}

class BorrowableBook : Book, IBorrowable
{
public bool IsAvailable { get; private set; } = true;
public void Borrow$Useruser$ {
if $!IsAvailable$ throw new Exception("Not available");
// отметить как выданную
IsAvailable = false;
// запись истории и пр.
}
}

class ReferenceBook : Book
{
// не реализует IBorrowable — нельзя использовать в LendingService как borrowable
}

Шаг 4 — выделить сервис для выдачи книг $SRP,DIP,OCP$

LendingService зависит от IBookRepository и IReportGenerator $черезабстракции$.

class LendingService
{
private readonly IBookRepository repo;
private readonly IReportGenerator report;

public LendingService$IBookRepositoryrepo,IReportGeneratorreport$ {
this.repo = repo;
this.report = report;
}
public void BorrowBook$stringid,Useruser$ {
var book = repo.GetById$id$;
if $book==null$ throw new Exception$"Notfound"$;
// проверяем, можно ли выдавать
if $bookisIBorrowableborrowable$ {
borrowable.Borrow$user$;
repo.SaveChanges;
report.GenerateLibraryReport$repo.GetAll()$;
}
else
{
throw new InvalidOperationException$"Thisbookcannotbeborrowed"$;
}
}

}

Результат

SRP: LibraryManager больше не выполняет сохранение и печать — это делают специализированные классы.DIP: LendingService зависит от абстракций $IBookRepository,IReportGenerator$, а не от конкретных File/Console.OCP: Добавление нового формата отчёта $например,HtmlReportGenerator$ не требует изменения LendingService.LSP: ReferenceBook больше не ломает поведение класса Book, т.к. модель разделена — код, ожидающий borrowable, работает только с IBorrowable.ISP: IBorrowable небольшой и точечный — клиенты реализуют только нужные методы.

4) Дополнительные рекомендации и переходный план

Внедрить конструкторное/контейнерное DI $втестахподменятьреализациирепозиториевигенераторов$.Добавить покрытие юнит-тестами: тестирование LendingService с mock-репозиторием и mock-репортером.Постепенно вынести остальные обязанности $регистрацияпользователей,штрафы,резервирование$ в отдельные сервисы.Проверять паттерны: если появляются разные типы книг с разным поведением — предпочесть композицию $поле/сервисповедения$ вместо «широкого» наследования.

5) Краткое сравнение «до» и «после»

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

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

преобразовать примеры в конкретный рабочий пример (полный код C# проекта);показать, как писать тесты для LendingService с использованием заглушек/моков;показать вариант с IoC-контейнером $например,Microsoft.Extensions.DependencyInjection$.