Низкоуровневое проектирование (LLD) — это критический этап разработки программного обеспечения, который устраняет разрыв между проектированием высокого уровня и фактической реализацией. В то время как проектирование высокого уровня фокусируется на архитектурных проектах, LLD занимается тем, как каждый компонент, класс или функция реализуется для удовлетворения общих требований системы.

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

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

Первый вопрос, который приходит нам в голову:

Почему важно низкоуровневое проектирование?

1. Удобство сопровождения: хорошо продуманный дизайн упрощает поддержку, расширение и отладку кода. Плохой дизайн приводит к техническому долгу, что делает будущие изменения дорогостоящими.
2. Масштабируемость: Хороший LLD гарантирует масштабируемость вашего кода как с точки зрения производительности, так и с точки зрения поддержки новых функций по мере развития системы.
3. Повторное использование: хорошо спроектированные компоненты можно повторно использовать в разных частях системы или в совершенно разных проектах.
4. Ясность: Благодаря четкому дизайну инженеры могут понять, как различные части системы сочетаются друг с другом, что упрощает совместную работу.

Чтобы устранить разрыв между концепциями LLD и реальным кодом, давайте разобьем процесс разработки низкоуровневой диаграммы на следующие этапы:

Шаг 1. Принципы объектно-ориентированного подхода
Шаг 2: ТВЕРДЫЕ ПРИНЦИПЫ
Шаг 3. Шаблоны проектирования

Объектно-ориентированные принципы

Концепция объектно-ориентированного программирования. Четыре столпа, которые необходимо сделать, чтобы начать изучать низкоуровневое проектирование. Я уже освещал эту концепцию в кратком блоге по оформлению заказа

НАДЕЖНЫЕ Принципы

S: Принцип единой ответственности (SRP)

• Каждая единица кода должна иметь только одну ответственность.
• Единицей может быть класс, модуль, функция или компонент.
• Сохраняет модульность кода и уменьшает тесную связь.

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

O: Принцип открытости/закрытости (OCP)

• Единицы кода должны быть открыты для расширения, но закрыты для модификации.
• Расширьте функциональность, добавляя новый код, а не изменяя существующий.
• Полезно в системах на основе компонентов, таких как интерфейс React.

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

L: Принцип замены Лискова (LSP)

• Подклассы должны заменять свои базовые классы.
• Функциональность базового класса должна быть доступна всем подклассам.
• Если подкласс не может использовать функциональность базового класса, его не должно быть в базовом классе.

Пример: если у нас есть класс Bird, имеющий метод fly(), и мы создаем подкласс Penguin, который не может летать, это нарушает LSP. Класс Penguin не должен наследовать функцию Fly(), поскольку это меняет ожидаемое поведение. Вместо этого класс Bird должен быть реорганизован для работы с птицами, которые могут и не могут летать по-разному.

I: Принцип разделения интерфейсов (ISP)

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

Пример: Предположим, у нас есть интерфейс Animal с методами Fly(), Swim() и Walk(). Класс Dog, реализующий Animal, будет вынужден определить функцию fly(), которая ему не нужна. Чтобы соответствовать требованиям ISP, нам следует разделить интерфейс Animal на более мелкие интерфейсы, такие как Flyable, Swimmable и Walkable, чтобы избежать использования ненужных методов в классах

D: Принцип инверсии зависимостей (DIP)

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

Пример: если в приложении электронной коммерции процесс оформления заказа (модуль высокого уровня) напрямую зависит от конкретного платежного шлюза, такого как PayPal (модуль низкого уровня), изменение платежного шлюза требует изменения процесса оформления заказа. Введя абстракцию, такую ​​как интерфейс PaymentProcessor, процесс оформления заказа может работать с любым способом оплаты без необходимости знать особенности PayPal или какой-либо другой службы.

Шаблоны проектирования

Шаблоны проектирования — это проверенные решения распространенных проблем, возникающих при проектировании программного обеспечения. Это лучшие практики, которым разработчики могут следовать для эффективного и систематического решения конкретных проблем проектирования. Вместо того, чтобы изобретать велосипед, шаблоны проектирования предоставляют стандартный подход к решению повторяющихся проблем.

Шаблоны проектирования можно разделить на три типа:

1. Шаблоны создания: работа с созданием объектов

   • Шаблон проектирования «Фабрика»
   • Абстрактный шаблон проектирования фабрики
   • Шаблон проектирования «Строитель»
   • Шаблон проектирования прототипа
   • Шаблон проектирования Singleton

2. Структурные шаблоны: работа с композицией объектов и отношениями

   • Шаблон адаптера
   • Узор «Мост»
   • Составной шаблон
   • Шаблон декоратора
   • Узор фасада
   • Модель наилегчайшего веса
   • Шаблон прокси

3. Модели поведения: взаимодействие с объектами и ответственность

   • Цепочка ответственности
   • Шаблон команды
   • Шаблон переводчика
   • Шаблон посредника
   • Узор на память
   • Шаблон наблюдателя
   • Шаблон состояния
   • Шаблон стратегии
   • Шаблон метода
   • Модель посетителей

Теперь, когда мы заложили основу, изучив принципы SOLID, и представили обширный ландшафт шаблонов проектирования, мы готовы погрузиться глубже! В следующей серии статей я разберу каждый шаблон проектирования с помощью практических примеров и сценариев из реальной жизни. Независимо от того, начинаете ли вы свой путь в дизайне или хотите отточить свои навыки, эти шаблоны помогут вам писать более чистый и масштабируемый код. Следите за обновлениями в следующем блоге, где мы шаг за шагом раскрываем первый шаблон проектирования!

Если вы зашли так далеко, не забудьте поставить лайк ❤️ и оставить комментарий ниже с любыми вопросами или мыслями. Ваш отзыв очень важен для меня, и мне бы хотелось услышать ваше мнение!