Принципы SOLID: что это и почему их используют все сеньоры
2026-02-21 05:54 Diff
https://skillbox.ru/media/code/principy-solid-chto-eto-i-pochemu-ih-ispolzuyut-vse-senory/

#статьи

  • 11 апр 2025
  • 0

SRP, OCP, LSP, ISP, DIP — разбираем основы современной архитектуры с примерами на Java.

Иллюстрация: Оля Ежак для Skillbox Media

Автор статей о программировании. 14 лет в IT. Умеет рассказывать о технологиях простыми словами. Автор спецпроекта Advertising for Social Change.

SOLID — это пять ключевых принципов проектирования классов в объектно-ориентированном программировании. Они помогают создавать понятный, гибкий и легко поддерживаемый код. Благодаря этим принципам архитектура приложения становится надёжнее и удобнее для развития. В статье мы познакомимся с каждым из них и разберём примеры на Java. Так что берите чашку кофе или чая — и начнём!

Содержание

Принципы SOLID сформулировал американский инженер-программист Роберт С. Мартин. В начале 2000-х он систематизировал подходы к объектно-ориентированному проектированию в статье Design Principles and Design Patterns. Позже, в 2004 году, консультант по разработке Майкл Физерс предложил объединить эти идеи под аббревиатурой SOLID:

  • S — single responsibility principle, принцип единственной ответственности.
  • O — open-closed principle, принцип открытости — закрытости.
  • L — Liskov substitution principle, принцип подстановки Барбары Лисков.
  • I — interface segregation principle, принцип разделения интерфейсов.
  • D — dependency inversion principle, принцип инверсии зависимостей.

Эти принципы помогают решать типичные проблемы объектно-ориентированных программ:

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

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

В следующих разделах мы разберём все принципы по очереди и потренируемся применять их на практике. Чтобы понять материал, вам понадобятся базовые знания Java и основ ООП. Если вы только начинаете изучать программирование, советуем сначала прочитать эти статьи:

Если вам так удобнее, вместо IntelliJ IDEA можно использовать VS Code с пакетом расширений Extension Pack for Java. Этого будет достаточно для запуска примеров из статьи — мы специально сделали их довольно простыми. Например, поля объявлены без private, геттеры и сеттеры не используются, а вместо реальной логики — просто System.out.println().

В реальных проектах код будет сложнее: с продуманной архитектурой, слоями, интерфейсами, тестами и другими практиками. Но когда вы только знакомитесь с SOLID, такие детали могут отвлекать от сути.

Принцип единственной ответственности означает, что каждый класс должен отвечать за одну задачу. Меняться он должен только по одной причине: изменилась логика в рамках его ответственности.

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

public class MainSRPViolation { public static void main(String[] args) { // Создаём книгу Book book = new Book("Clean Code", "Robert C. Martin", 40); // Создаём счёт на 3 экземпляра книги Invoice invoice = new Invoice(book, 3); // Печатаем счёт invoice.printInvoice(); // Сохраняем счёт в файл invoice.saveToFile("invoice.txt"); } } // Книга — просто данные class Book { String name; String authorName; int price; public Book(String name, String authorName, int price) { this.name = name; this.authorName = authorName; this.price = price; } } // Invoice нарушает SRP: отвечает за расчёт, за вывод и сохранение class Invoice { Book book; int quantity; double total; public Invoice(Book book, int quantity) { this.book = book; this.quantity = quantity; this.total = calculateTotal(); } // Считаем сумму public double calculateTotal() { return book.price * quantity; } // Печатаем счёт public void printInvoice() { System.out.println(quantity + "x " + book.name + " " + book.price + "$"); System.out.println("Total: " + total + "$"); } // Сохраняем счёт (имитация процесса) public void saveToFile(String filename) { System.out.println("Сохраняем счёт в файл: " + filename); } }

Результат вывода:

3x Clean Code 40$ Total: 120.0$ Сохраняем счёт в файл: invoice.txt

На первый взгляд, всё кажется логичным, но на деле этот класс нарушает первый принцип SOLID сразу в нескольких местах:

  • Метод printInvoice() отвечает за вывод счёта. Если нужно изменить формат отображения — например, добавить поддержку PDF или HTML, — придётся редактировать сам класс Invoice, что нарушает принцип единственной ответственности. Логика отображения не должна смешиваться с бизнес-логикой.
  • Метод saveToFile() отвечает за сохранение счёта в файл. Но если в будущем потребуется сохранять данные, например, в базу данных или отправлять их по API, снова придётся править класс Invoice.

В итоге один класс выполняет сразу три задачи: рассчитывает итоговую стоимость, выводит счёт и сохраняет данные в файл. Любое изменение способа вывода или хранения потребует вмешательства в бизнес-логику. Это нарушает принцип SRP и усложняет поддержку кода.

Нарушение SRP: Invoice совмещает логику расчёта, вывода и сохранения
Изображение: Mermaid Chart / Skillbox Media

Чтобы соблюдать принцип единственной ответственности, разделим задачи между классами: Invoice будет рассчитывать стоимость заказа, InvoicePrinter — выводить счёт, а InvoicePersistence — сохранять его:

public class MainSRPRefactored { public static void main(String[] args) { // Создаём книгу Book book = new Book("Clean Code", "Robert C. Martin", 40); // Создаём счёт на 3 книги Invoice invoice = new Invoice(book, 3); // Печатаем счёт InvoicePrinter printer = new InvoicePrinter(invoice); printer.print(); // Сохраняем счёта InvoicePersistence persistence = new InvoicePersistence(invoice); persistence.saveToFile("invoice.txt"); } } // Книга — просто данные class Book { public String name; public String authorName; public int price; public Book(String name, String authorName, int price) { this.name = name; this.authorName = authorName; this.price = price; } } // Счёт — расчёт суммы и данные заказа class Invoice { public Book book; public int quantity; public double total; public Invoice(Book book, int quantity) { this.book = book; this.quantity = quantity; this.total = book.price * quantity; } } // Вывод счёта — отдельная задача class InvoicePrinter { private Invoice invoice; public InvoicePrinter(Invoice invoice) { this.invoice = invoice; } public void print() { System.out.println(invoice.quantity + "x " + invoice.book.name + " " + invoice.book.price + "$"); System.out.println("Total: " + invoice.total + "$"); } } // Сохранение счёта — отдельная задача class InvoicePersistence { private Invoice invoice; public InvoicePersistence(Invoice invoice) { this.invoice = invoice; } public void saveToFile(String filename) { System.out.println("Сохраняем в файл: " + filename); System.out.println("Содержимое:"); System.out.println(invoice.quantity + "x " + invoice.book.name + " " + invoice.book.price + "$"); System.out.println("Total: " + invoice.total + "$"); } }

Результат вывода:

3x Clean Code 40$ Total: 120.0$ Сохраняем в файл: invoice.txt Содержимое: 3x Clean Code 40$ Total: 120.0$

После такого разделения каждый компонент отвечает только за свою задачу. Теперь можно легко менять формат вывода в InvoicePrinter или способ хранения в InvoicePersistence, не затрагивая бизнес-логику в классе Invoice. Это делает код более гибким и простым в поддержке.

Каждый класс отвечает за своё: Invoice — за данные и расчёт, InvoicePrinter — за вывод, InvoicePersistence — за сохранение
Изображение: Mermaid Chart / Skillbox Media

Согласно этому принципу, код должен быть открыт для расширения, но закрыт для изменения. Если нужно добавить новую функциональность, лучше реализовать её отдельно, а не переписывать существующий класс. Чаще всего для этого используют интерфейсы или абстрактные классы.

Допустим, у нас уже есть приложение для выставления счетов, и начальник просит добавить сохранение счетов в базу данных. Что приходит в голову в первую очередь? Просто дописать метод saveToDatabase() в уже существующий класс InvoicePersistence:

public class MainOCPViolation { public static void main(String[] args) { // Каждый раз при добавлении нового способа сохранения // приходится менять класс InvoiceSaver, — это нарушение OCP Book book = new Book("Clean Code", "Robert C. Martin", 40); Invoice invoice = new Invoice(book, 3); InvoiceSaver saver = new InvoiceSaver(invoice); // Сохраняем счёт в файл saver.saveToFile("invoice.txt"); // Сохраняем счёт в базу данных saver.saveToDatabase(); } } // Книга — просто данные class Book { String name; String authorName; int price; public Book(String name, String authorName, int price) { this.name = name; this.authorName = authorName; this.price = price; } } // Счёт — хранит данные и рассчитывает сумму class Invoice { Book book; int quantity; double total; public Invoice(Book book, int quantity) { this.book = book; this.quantity = quantity; this.total = book.price * quantity; } } // Saver нарушает OCP — он жёстко привязан к способам сохранения class InvoiceSaver { Invoice invoice; public InvoiceSaver(Invoice invoice) { this.invoice = invoice; } // Сохранение в файл public void saveToFile(String filename) { System.out.println("Сохраняем счёт в файл: " + filename); } // Сохранение в базу данных public void saveToDatabase() { System.out.println("Сохраняем счёт в базу данных..."); } // Если разработчику нужно будет добавить в проект MongoDB, API или облачную базу данных, придётся снова менять этот класс }

Вывод в консоль при запуске кода:

Сохраняем счёт в файл: invoice.txt Сохраняем счёт в базу данных...

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

Нарушение OCP: при добавлении новых способов сохранения нужно менять InvoicePersistence
Изображение: Mermaid Chart / Skillbox Media

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

package refactored.ocp; public class MainOCPRefactored { public static void main(String[] args) { // Создаём книгу Book book = new Book("Clean Code", "Robert C. Martin", 40); // Создаём счёт на 3 книги Invoice invoice = new Invoice(book, 3); // Выбираем способ сохранения — в данном случае в файл // Используем интерфейс, не трогая код Invoice или Main InvoicePersistence persistence = new FilePersistence(); persistence.save(invoice); // Хотим сохранить в базу? Просто создаём другую реализацию: // InvoicePersistence persistence = new DatabasePersistence(); // persistence.save(invoice); } } // Книга — просто набор данных class Book { public String name; public String authorName; public int price; public Book(String name, String authorName, int price) { this.name = name; this.authorName = authorName; this.price = price; } } // Счёт — хранит данные и считает итоговую сумму class Invoice { public Book book; public int quantity; public double total; public Invoice(Book book, int quantity) { this.book = book; this.quantity = quantity; this.total = book.price * quantity; } } // Интерфейс для всех способов сохранения interface InvoicePersistence { void save(Invoice invoice); } // Сохраняем счёт в файл class FilePersistence implements InvoicePersistence { @Override public void save(Invoice invoice) { System.out.println("Сохраняем счёт в файл: invoice.txt"); } } // Сохраняем счёт в базу данных class DatabasePersistence implements InvoicePersistence { @Override public void save(Invoice invoice) { System.out.println("Сохраняем счёт в базу данных..."); } }

Если запустить код как есть, в консоли появится сообщение:

Сохраняем счёт в файл: invoice.txt

Однако, если вы раскомментируете строку с DatabasePersistence, а FilePersistence закомментируете, результат будет другим:

Сохраняем счёт в базу данных...

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

Принцип OCP: новые классы (FilePersistence, DatabasePersistence) добавляются без изменения существующего кода
Изображение: Mermaid Chart / Skillbox Media

Принцип подстановки Лисков (LSP) устанавливает важное правило для наследования: если в программе используется базовый класс, то любой его подкласс должен работать так же корректно, как и родительский класс. Подкласс не должен нарушать ожидаемое поведение программы.

Представьте класс Rectangle, который описывает прямоугольник и вычисляет его площадь. Нам требуется создать класс Square, поскольку квадрат — частный случай прямоугольника с равными сторонами:

public class MainLSPViolation { public static void main(String[] args) { // Прямоугольник — всё работает как ожидалось Rectangle rc = new Rectangle(2, 3); AreaFixedHeight.getArea(rc); // Ожидаемая площадь: 20 // Квадрат — это наследник прямоугольника, но он меняет поведение setWidth и setHeight Rectangle sq = new Square(); sq.setWidth(5); // Ожидаем, что изменится только ширина // Но у квадрата меняются сразу обе стороны — ширина и высота AreaFixedHeight.getArea(sq); // Ожидаемая площадь: 50, но получим другую } } // Прямоугольник — базовый класс с шириной и высотой class Rectangle { protected int width, height; public Rectangle() {} public Rectangle(int width, int height) { this.width = width; this.height = height; } public int getWidth() { return width; } public void setWidth(int width) { this.width = width; } public int getHeight() { return height; } public void setHeight(int height) { this.height = height; } public int getArea() { return width * height; } } // Квадрат меняет поведение родителя и ломает логику class Square extends Rectangle { public Square() {} public Square(int size) { width = height = size; } @Override public void setWidth(int width) { // Меняем ширину и высоту одновременно super.setWidth(width); super.setHeight(width); } @Override public void setHeight(int height) { // Меняем высоту и ширину — снова ломаем контракт super.setHeight(height); super.setWidth(height); } } // Метод расчёта площади прямоугольника с фиксированной высотой class AreaFixedHeight { static void getArea(Rectangle r) { int width = r.getWidth(); // Сохраняем начальную ширину r.setHeight(10); // Меняем только высоту System.out.println("Ожидаемая площадь: " + (width * 10) + ", полученная: " + r.getArea()); } }

Казалось бы: если мы меняем ширину квадрата, автоматически меняется и высота, и наоборот. Но что может пойти не так? Например, код, рассчитанный на работу с прямоугольником с фиксированной высотой, может выдать неожиданный результат, если передать ему объект Square:

Ожидаемая площадь: 20, полученная: 20 Ожидаемая площадь: 50, полученная: 100

При вызове AreaFixedHeight.getArea(sq) мы наблюдаем неожиданное поведение: метод рассчитан на работу с объектами Rectangle и предполагает, что и��менение высоты никак не влияет на ширину. Однако в Square метод setHeight() переопределён так, что меняет оба параметра одновременно. Это нарушает третий принцип SOLID: поведение подкласса отличается от поведения базового класса, и такая подстановка приводит к ошибкам.

Нарушение LSP: класс Square наследуется от Rectangle, но переопределяет методы так, что ломает ожидаемое поведение
Изображение: Mermaid Chart / Skillbox Media

В нашем случае Square не должен наследоваться от Rectangle, потому что их поведение различается. Вместо этого лучше создать общий интерфейс Shape и реализовать его отдельно в обоих классах, — так мы избегаем проблем с подстановкой и соблюдаем принцип LSP:

package refactored.lsp; public class MainLSPRefactored { public static void main(String[] args) { // Прямоугольник и квадрат реализуют один интерфейс Shape rectangle = new Rectangle(2, 10); // прямоугольник 2 × 10 Shape square = new Square(5); // квадрат 5 × 5 // Метод printArea() работает с любой фигурой printArea(rectangle); // Площадь: 20 printArea(square); // Площадь: 25 } // Универсальный метод для обработки любой фигуры static void printArea(Shape shape) { System.out.println("Площадь: " + shape.getArea()); } } // Интерфейс с методом для вычисления площади interface Shape { int getArea(); } // Прямоугольник: ширина × высота class Rectangle implements Shape { private int width, height; public Rectangle(int width, int height) { this.width = width; this.height = height; } @Override public int getArea() { return width * height; } } // Квадрат: стороны равны class Square implements Shape { private int size; public Square(int size) { this.size = size; } @Override public int getArea() { return size * size; } }

Лог в консоли:

Площадь: 20 Площадь: 25

Теперь Rectangle и Square — независимые классы, каждый со своей реализацией интерфейса Shape. Rectangle свободно управляет шириной и высотой, тогда как Square сохраняет равенство всех сторон.

Соблюдение LSP: Rectangle и Square реализуют общий интерфейс Shape — подстановка работает корректно, без нарушения поведения
Изображение: Mermaid Chart / Skillbox Media

Суть принципа разделения интерфейсов (ISP) заключается в том, что интерфейсы должны быть узкими и специализированными. Вместо одного большого интерфейса лучше создавать несколько маленьких — каждый со своей задачей. За счёт такого подхода классы могут реализовывать только те методы, что действительно нужны для их работы.

Представим, что у нас есть интерфейс Employee, в котором собраны три обязанности сотрудника: работать, есть и отдыхать. Давайте напишем программу:

public class MainISPViolation { public static void main(String[] args) { // Два сотрудника с разным поведением Employee dev = new Developer(); Employee manager = new Manager(); // Все сотрудники вызывают одни и те же методы dev.work(); dev.eat(); dev.relax(); manager.work(); manager.eat(); manager.relax(); } } // Интерфейс объединяет все обязанности — без разделения по ролям interface Employee { void work(); void eat(); void relax(); } // Разработчику подходят все методы class Developer implements Employee { public void work() { System.out.println("Разработчик пишет код..."); } public void eat() { System.out.println("Разработчик обедает..."); } public void relax() { System.out.println("Разработчик отдыхает..."); } } // Менеджер вынужден реализовывать лишние методы class Manager implements Employee { public void work() { System.out.println("Менеджер проводит встречи..."); } public void eat() { System.out.println("Менеджеры не обедают..."); } public void relax() { System.out.println("Менеджеры не отдыхают..."); } }

Результат выполнения программы:

Разработчик пишет код... Разработчик обедает... Разработчик отдыхает... Менеджер проводит встречи... Менеджеры не обедают... Менеджеры не отдыхают...

Каждый класс, который использует интерфейс Employee, должен описывать все три метода. Представим двух сотрудников:

  • Разработчик (Developer) — работает, обедает и отдыхает.
  • Менеджер (Manager) — только работает, без обедов и перерывов.

В этом случае Manager всё равно вынужден добавлять лишние методы, которые не используются. Это нарушает принцип разделения интерфейсов.

Нарушение ISP: интерфейс Employee включает всё сразу, и приходится реализовывать даже ненужные методы
Изображение: Mermaid Chart / Skillbox Media

Давайте разделим интерфейс Employee на несколько узких интерфейсов — так каждый класс сможет реализовать только нужные ему методы:

package refactored.isp; public class MainISPRefactored { public static void main(String[] args) { // Разработчик реализует все необходимые интерфейсы Workable dev = new Developer(); dev.work(); // Дополнительно можно вызвать обед и перерыв: // ((Lunchable) dev).eatLunch(); // ((Breakable) dev).takeBreak(); // Менеджер реализует только нужный интерфейс Workable manager = new Manager(); manager.work(); } } // Интерфейс для работы interface Workable { void work(); } // Интерфейс для обеда interface Lunchable { void eatLunch(); } // Интерфейс для перерыва interface Breakable { void takeBreak(); } // Разработчик работает, ест и отдыхает class Developer implements Workable, Lunchable, Breakable { @Override public void work() { System.out.println("Разработчик пишет код..."); } @Override public void eatLunch() { System.out.println("Разработчик обедает..."); } @Override public void takeBreak() { System.out.println("Разработчик отдыхает..."); } } // Менеджер только работает class Manager implements Workable { @Override public void work() { System.out.println("Менеджер проводит встречи..."); } }

Информация в консоли:

Разработчик пишет код... Менеджер проводит встречи...

Теперь интерфейс Employee разделён на три отдельных интерфейса: Workable, Lunchable и Breakable. Получается следующее:

  • Developer реализует все три — он работает, обедает и отдыхает.
  • Manager реализует только Workable — ничего лишнего.

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

Соблюдение ISP: интерфейсы разделены по задачам — каждый класс реализует только нужные методы
Изображение: Mermaid Chart / Skillbox Media

Принцип инверсии зависимостей (DIP) означает, что модули высокого уровня должны зависеть от абстракций, а не от модулей низкого уровня. Под модулями высокого уровня обычно понимают бизнес-логику приложения — например, управление пользователями или обработку заказов. Модули низкого уровня — это конкретные технические реализации: работа с базой данных, API или файловой системой.

Если класс напрямую зависит от другой конкретной реализации, его сложно тестировать и модифицировать. Роберт Мартин пишет:

«Если OCP описывает цель объектно-ориентированной архитектуры, то DIP — это основной механизм её достижения».

Эти два принципа тесно связаны: чтобы классы были открыты для расширения (OCP), нужно отказаться от жёстких зависимостей в пользу абстракций (DIP). Представьте себе конструктор LEGO: вместо того чтобы детали были наглухо склеены, они соединяются через стандартные разъёмы — как интерфейсы в коде. Благодаря этому можно легко заменять одни блоки на другие, не ломая всю конструкцию.

Пусть у нас есть класс OrderService, который отвечает за обработку заказов и напрямую зависит от конкретной реализации — класса MySQLDatabase:

public class MainDIPViolation { public static void main(String[] args) { // OrderService напрямую зависит от конкретной базы данных (MySQL) OrderService orderService = new OrderService(); // Сохраняем заказ orderService.saveOrder(new Order("Заказ №1")); } } // OrderService зависит от реализации MySQLDatabase class OrderService { private MySQLDatabase database; public OrderService() { // Создание конкретной реализации внутри класса this.database = new MySQLDatabase(); } public void saveOrder(Order order) { database.save(order); } } // Хранилище на базе MySQL — модуль низкого уровня class MySQLDatabase { public void save(Order order) { System.out.println("Сохраняем заказ в MySQL: " + order.description); } } // Данные о заказе class Order { public String description; public Order(String description) { this.description = description; } }

Результат выполнения кода:

Сохраняем заказ в MySQL: Заказ №1

В примере выше OrderService привязан к MySQLDatabase: объект создаётся внутри класса и не может быть подменён. Поэтому, чтобы заменить базу данных или протестировать сервис без реального подключения, придётся менять сам OrderService. Это нарушает принцип DIP, поскольку бизнес-логика зависит от конкретной реализации, а не от абстракции.

Нарушение DIP: OrderService зависит от MySQLDatabase, что затрудняет тестирование и переиспользование кода
Изображение: Mermaid Chart / Skillbox Media

Создадим интерфейс, который будет абстракцией для хранения данных.

package refactored.dip; public class MainDIPRefactored { public static void main(String[] args) { // Две разные реализации репозитория OrderRepository mysqlRepo = new MySQLDatabase(); OrderRepository mongoRepo = new MongoDBDatabase(); // OrderService работает через интерфейс — не зависит от конкретной базы OrderService orderService1 = new OrderService(mysqlRepo); OrderService orderService2 = new OrderService(mongoRepo); // Сохраняем заказы с разными источниками данных orderService1.saveOrder(new Order("Заказ №1")); orderService2.saveOrder(new Order("Заказ №2")); } } // Абстракция для хранилища заказов interface OrderRepository { void save(Order order); } // Реализация для MySQL class MySQLDatabase implements OrderRepository { @Override public void save(Order order) { System.out.println("Сохраняем заказ в MySQL: " + order.description); } } // Реализация для MongoDB class MongoDBDatabase implements OrderRepository { @Override public void save(Order order) { System.out.println("Сохраняем заказ в MongoDB: " + order.description); } } // OrderService — бизнес-логика, зависит только от интерфейса class OrderService { private final OrderRepository repository; public OrderService(OrderRepository repository) { this.repository = repository; } public void saveOrder(Order order) { repository.save(order); } } // Класс с данными о заказе class Order { public String description; public Order(String description) { this.description = description; } }

Сообщение в консоли:

Сохраняем заказ в MySQL: Заказ №1 Сохраняем заказ в MongoDB: Заказ №2

Теперь OrderService зависит не от конкретной реализации репозитория, а от абстракции — интерфейса OrderRepository. Такой подход позволяет подключать разные реализации хранилища данных (например, MySQL, MongoDB и другие) без изменения кода самого сервиса. В этом и заключается принцип инверсии зависимостей: модули высокого уровня должны зависеть от абстракций, а не от конкретных реализаций.

Соблюдение DIP: OrderService зависит от интерфейса OrderRepository, а не от конкретной реализации базы данных
Изображение: Mermaid Chart / Skillbox Media Курс с трудоустройством: «Профессия Java-разработчик + ИИ» Узнать о курсе