Это должен быть один из распространенных вопросов, которые вы услышите на собеседовании. Но там, очевидно, у вас будет всего 5 минут, чтобы доказать, что вы это знаете.
Я здесь, чтобы убедиться, что у вас это есть! SOLID – одна из наиболее важных аббревиатур в мире объектно-ориентированного программирования.
Почему вы должны заботиться о ТВЕРДОМ программировании? Прежде всего, вы должны понять, что вы не собираетесь вечно оставаться там, где вы есть. Если мы используем стандарты и хорошо известные архитектуры, мы можем быть уверены, что наш код будет легко поддерживать другим разработчикам, которые придут после нас, и я уверен, что вы не захотите решать задачу исправления кода, в котором не применялась какая-либо известная методология, так как это было бы очень трудно понять.
Давайте сразу перейдем к делу.
Что означает SOLID? S — Принцип Единой Ответственности. O — Принцип Открытого Закрытия. L — Принцип замещения Лискова. I — Принцип Разделения Интерфейсов. D — Принцип Инверсии Зависимостей.
Принцип Единой Ответственности:
У класса должна быть только одна причина для изменения.
Как следует из названия, этот принцип подразумевает, что класс/модуль должен делать только одно, нести только одну ответственность. Если наш класс выполняет более одной задачи, то мы должны разделить функциональные возможности на разные классы. В контексте Принципа единой ответственности (SRP) мы определяем ответственность как “причину изменений”. Если вы можете придумать более одного мотива для смены класса, то этот класс несет более одной ответственности.
Пример. Давайте предположим, что у нас есть Телефон который имеет различные функции, такие как звонки, обмен сообщениями, калькулятор, фонарик и т.д. Теперь, когда мы определим этот класс, у нас будет один телефон.java-файл, который будет содержать все функции. Теперь этот класс нарушает принцип SRP, поскольку на этот класс было возложено несколько обязанностей. Чтобы класс перестал нарушать принцип, мы должны определить обязанности в отдельных классах, таких как Calling.java , Messaging.java , Calculator.java , таким образом, создавая короткие компоненты/классы и разделяя обязанности.
Конкретный пример для Android. Метод onBindViewHolder виджета RecyclerView . Роль onBindViewHolder заключается в сопоставлении элемента списка с представлением. В этом методе не должно быть никакой логики. Так что, если есть какой-либо код, относящийся к логике, вам, вероятно, следует удалить его оттуда.
Принцип Открытого Закрытого:
Программные объекты (классы, модули, функции и т.д.) должны быть открыты для расширения, но закрыты для модификации.
Это в основном означает, что мы должны добавлять точки расширения в классы, которые реализуют требования, которые по своей сути нестабильны из-за нестабильности в бизнес-домене, и проводить рефакторинг частей кода и вводить дополнительные точки расширения, когда эти части оказались нестабильными.
Конкретный пример для Android. Расширение RecyclerView. Класс Adapter прост, и мы можем легко создавать пользовательские адаптеры. Разработчики могут легко расширить этот класс и создать свой собственный пользовательский адаптер с настраиваемым поведением, не изменяя существующий RecyclerView. Адаптер класс. Еще Один Пример. можно смотреть на Кнопки , Переключатели , Флажки наследуют все от TextView класса. Это означает, что TextView открыт для расширения, но закрыт для изменений.
Принцип замещения Лискова:
Объекты в программе должны быть заменены экземплярами их подтипов без изменения поведения этой программы.
Это означает, что подкласс должен переопределять методы родительского класса, которые не нарушают функциональность родительского класса.
Пример. В математике Квадрат – это прямоугольник. Действительно, это специализация прямоугольника. “Есть” заставляет вас хотеть смоделировать это с помощью наследования. Однако, если в коде вы сделали квадрат производным от прямоугольника, то Квадрат следует использовать везде, где вы ожидаете увидеть прямоугольник. Это приводит к некоторому странному поведению. Представьте, что у вас были методы setWidth и setHeight в базовом классе Rectangle; это кажется совершенно логичным. Однако, если ваша ссылка на прямоугольник указывает на квадрат, то setWidth и setHeight не имеют смысла, потому что установка одного приведет к изменению другого в соответствии с ним. В этом случае Квадрат не проходит тест на замену Лискова Прямоугольником, и абстракция того, что квадрат наследуется от прямоугольника, является плохой.
Конкретный пример для Android. Мы должны написать пользовательский класс адаптера RecyclerView таким образом, чтобы он все еще работал с RecyclerView. Мы не должны писать что-то, что приведет к неправильному поведению RecyclerView.
Принцип разделения интерфейсов:
Классы, реализующие интерфейсы, не должны быть вынуждены реализовывать методы, которые они не используют.
Это означает, что если интерфейс становится слишком толстым, то его следует разделить на более мелкие интерфейсы, чтобы клиент, реализующий интерфейс, не реализовывал методы, которые ему бесполезны. ISP относится к важным характеристикам — сцеплению и сцеплению. В идеале ваши компоненты должны быть тщательно подобраны. Это повышает надежность и ремонтопригодность кода.
Интернет-провайдер предоставляет вам следующие бонусы: Высокая когезия — лучшая понятность, надежность. Низкое сцепление — лучшая ремонтопригодность, высокая устойчивость к изменениям.
Пример. Снова возвращаясь к предыдущему примеру телефона, если у нас есть общедоступный интерфейс для всей функциональности, например:
Теперь, если вы хотите реализовать калькулятор, функции dial() , Lighton() и lightOff() бесполезны. Таким образом, мы должны реорганизовать код примерно так:
Теперь нужный класс может реализовать один или несколько интерфейсов по желанию. Вот как мы можем предотвратить нарушение правил интернет-провайдера.
Принцип Инверсии Зависимостей:
Модули высокого уровня не должны зависеть от модулей низкого уровня. И то, и другое должно зависеть от абстракций.
и
Абстракции не должны зависеть от деталей. Детали должны зависеть от абстракций.
Если вы используете класс внутри другого класса, этот класс будет зависеть от введенного класса. Важность DIP можно свести к единственной цели – возможности повторного использования программных компонентов, часть функциональности которых зависит от внешних зависимостей.
Пример. Если у нас есть класс Bank, который имеет следующий код, вызывающий класс Bank не знает о скрытых зависимостях, таким образом, это нарушает DIP.
С другой стороны, если мы изменим код на что-то вроде этого:
В этом случае мы позволяем вызывающему классу банка знать о соответствующих зависимостях, вместо того, чтобы позволять самому классу создавать зависимость. Это также помогает в случае тестирования!
Вывод: Принципы SOLID являются одними из наиболее важных принципов, которые необходимо изучить и реализовать, если вы придерживаетесь объектно-ориентированного проектирования. Поначалу это может показаться немного ошеломляющим, но с практикой и временем вы будете кодировать на основе этих принципов, даже не осознавая этого. (Скопировано из StackOverflow:D)
Наслаждайтесь! Счастливого кодирования! Не стесняйтесь оставлять комментарии, если что-то непонятно или если у вас есть вопросы.
— Пиюш Махешвари.
В случае, если вы хотите связаться с нами: Твиттер
Оригинал: “https://dev.to/piyush2769/piyush-talks-about-solid-principles-4h1m”