SOLID ПРИНЦИПЫ простым языком (много примеров)

Понимание ТВЕРДЫХ принципов Принципы SOLID являются важными правилами и ограничениями при разработке программного обеспечения. Они позволяют разработчикам эффективно взаимодействовать, разрабатывать масштабируемые приложения и минимизировать барьеры знаний, связанные с конкретным проектом.

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

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

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

Декомпозиция для удобства обслуживания Декомпозиция объектов на более мелкие модули обеспечивает параллельную разработку, упрощает управление версиями с помощью Git и упрощает тестирование с помощью автоматических тестов. Это также предотвращает конфликты в больших объектах, распределяя конкретные задачи по отдельным компонентам.

Шаблон хранилища для обработки данных Использование шаблона репозитория отделяет логику хранения данных от других классов, таких как контроллеры или HTTP-отправители. Это разделение позволяет вносить локализованные изменения, не затрагивая всю систему, и способствует лучшей организации операций обработки данных.

Разделение логики обслуживания пользователей Логика "пользовательского сервиса" отделена от логики "хранилища", чтобы независимо обрабатывать операции, связанные с пользователем. У каждого класса есть своя зона ответственности, что приводит к модульным и повторно используемым сегментам кода.

Обязанности компонентов Компоненты разрабатываются с акцентом на конкретные обязанности, такие как рендеринг форм, правила проверки, основанные на различных критериях (например, международные или местные), обеспечивая четкое разделение задач в архитектуре приложения.

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

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

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

Сущность функций Понимание сути функций и их использования в родительских и дочерних классах. Обеспечение того, чтобы производные классы дополняли или заменяли поведение базового класса без нарушения логики программы.

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

Реалистичный пример: Операции с базой данных Изучение операций с базами данных с использованием реляционных (SQL) и нереляционных баз данных, подчеркивание важности соблюдения принципа подстановки Лискова при модификации методов для конкретных типов баз данных.

Состав компонентов "Component" "Разложение компонентов на отдельные сущности на основе определенных атрибутов, подчеркивающее прозрачную структуру по сравнению с непрозрачной композицией для лучшей организации кода и удобства сопровождения.

Принцип замещения Интернет-провайдер нарушает принцип замещения, который предполагает разбиение интерфейсов и программных объектов на более мелкие специализированные компоненты.

Принцип разделения интерфейсов Интернет-провайдер делает акцент на разделении больших интерфейсов и программных объектов на более мелкие, более специализированные, чтобы предотвратить зависимость от неиспользуемых методов. Его цель - разрабатывать интерфейсы, адаптированные для конкретных клиентов, а не создавать чрезмерно общие решения.

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

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

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

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

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

Абстракция клиент-сервер Использование экземпляра класса "Indeks Music API" эволюционирует в интеграцию музыкального сервиса "Spotify", требующую корректировки названия метода в различных областях приложения. Создание общего интерфейса обеспечивает полиморфизм при сохранении гибкости для будущих изменений, таких как добавление поддержки VK Music позже.

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

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

Принцип замещения Лискова Объекты в программе должны быть заменяемы экземплярами их подклассов, не влияя на логику программы.

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

Принцип инверсии зависимостей "Высокоуровневые модули не должны зависеть от низкоуровневых модулей; оба должны зависеть от абстракций." Не должно быть зависимостей от конкретных реализаций; вместо этого всегда должна существовать некоторая форма абстракции между высокоуровневыми и низкоуровневыми модулями

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