В этом посте мы увидим 5 ТВЕРДЫХ принципов в Java.
Роберт К. Мартин дал пять принципов объектно-ориентированного проектирования, и для этого используется аббревиатура “S.O.L.I.D”. Каждая буква этой аббревиатуры говорит о принципах в Java . Когда вы используете все принципы S.O.L.I.D в сочетании, вам становится легче разрабатывать программное обеспечение, которым можно легко управлять. Другими особенностями использования S.O.L.I.D являются:
- Это позволяет избежать запахов кода
- Быстрый рефакторинг кода
- Может заниматься адаптивной или гибкой разработкой программного обеспечения
Когда вы используете принцип S.O.L.I.D в своем кодировании, вы начинаете писать код, который является одновременно эффективным и действенным.
В чем смысл S.O.L.I.D?
Как указывалось выше, S.O.L.I.D представляет пять принципов Java, которые являются:
- Субъекты: Принцип единой ответственности
- O: Принцип “открыто-закрыто”
- L: Принцип замещения Лискова
- I: Принцип разделения интерфейсов
- D: Принцип инверсии зависимостей
В статье подробно рассматривается каждый из этих принципов. Мы начнем с рассмотрения самого первого принципа, который является принципом единой ответственности.
Принцип единой ответственности (SRP)
Согласно принципу единой ответственности , должна быть только одна причина, по которой класс должен быть изменен. Это означает, что у класса должна быть одна задача для выполнения. Этот принцип часто называют субъективным.
Принцип можно хорошо понять на примере. Представьте, что существует класс, который выполняет следующие операции.
- подключен к базе данных
- считывание некоторых данных из таблиц базы данных
- наконец, запишите его в файл.
Вы представляли себе этот сценарий? Здесь у класса есть несколько причин для изменения, и некоторые из них – это изменение вывода файла, внедрение новой базы данных. Когда мы говорим об ответственности за единый принцип, мы бы сказали, что существует слишком много причин для изменения класса; следовательно, он не вписывается должным образом в принцип единой ответственности.
Принцип Открытого Закрытого
Согласно принципу open closed , сущности или объекты должны оставаться открытыми для расширения, но они должны оставаться закрытыми для модификации. Чтобы быть точным, в соответствии с этим принципом, класс должен быть написан таким образом, чтобы он выполнял свою работу безупречно, не предполагая, что люди в будущем просто придут и изменят его. Следовательно, класс должен оставаться закрытым для модификации, но у него должна быть возможность расширения. Способы расширения класса включают:
- Наследование от класса
- Перезапись требуемого поведения из класса
- Расширение определенных поведений класса
Отличный пример открытого закрытого принципа можно понять с помощью браузеров. Вы помните, как устанавливали расширения в свой браузер Chrome?
Основной функцией браузера Chrome является просмотр различных сайтов. Вы хотите проверить грамматику, когда пишете электронное письмо с помощью браузера Chrome? Если да, вы можете просто использовать расширение Grammarly, оно обеспечивает проверку грамматики содержимого.
Этот механизм, в котором вы добавляете что-то для увеличения функциональности браузера, является расширением. Следовательно, браузер является прекрасным примером функциональности, которая открыта для расширения, но закрыта для модификации. Проще говоря, вы можете расширить функциональность, добавив/установив плагины в свой браузер, но не можете создать ничего нового.
Давайте возьмем другой пример. Вы используете любую функциональность Spring function. Очевидно, что вы не можете изменить его основную логику, но вы можете расширить классы Spring framework и создать свой собственный.
Принцип замещения Лискова
Принцип подстановки Лискова предполагает, что q (x) является свойством, доказуемым для объектов x, принадлежащих типу T. Теперь, в соответствии с этим принципом, q (y) теперь должно быть доказуемым для объектов y, принадлежащих типу S, а S фактически является подтипом T. Вы сейчас в замешательстве и не знаете, что на самом деле означает принцип замены Лискова? Определение этого может быть немного сложным, но на самом деле это довольно просто. Единственное, что каждый подкласс или производный класс должен быть заменяемым для своего родительского или базового класса.
Можно сказать, что это уникальный объектно-ориентированный принцип. Принцип можно еще больше упростить, поняв этот принцип; дочерний тип определенного родительского типа без каких-либо усложнений или взрывов должен иметь возможность заменять этого родителя. Этот принцип тесно связан с принципом замещения Лискова.
Принцип разделения Интерфейсов
Согласно принципу разделения интерфейсов , клиент, несмотря ни на что, никогда не должен быть вынужден реализовывать интерфейс, который он не использует, или клиент никогда не должен быть обязан зависеть от какого-либо метода, который им не используется.
Итак, в принципе, принципы разделения интерфейсов таковы, как вы предпочитаете интерфейсы, которые являются небольшими, но специфичными для клиента, вместо монолитного и большего интерфейса.
Короче говоря, с вашей стороны было бы плохо заставлять клиента зависеть от определенной вещи, которая ему не нужна.
Давайте теперь снова возьмем пример, чтобы понять это.
Давайте возьмем простой пример. Вы реализуете свой собственный ArrayList и LinkedList на java. Вы создаете интерфейс под названием List, который будут реализовывать оба класса.
package org.arpit.java2blog; public interface List{ public T get(); public void add(T t); public T poll(); public T peek(); }
package org.arpit.java2blog; public class LinkedList implements List{ @Override public Integer get() { // Implement this method return null; } @Override public void add(Integer t) { // Implement this method } @Override public Integer poll() { // Implement this method return null; } @Override public Integer peek() { // Implement this method return null; } }
Давайте теперь создадим класс ArrayList.
package org.arpit.java2blog; public class ArrayList implements List{ @Override public Integer get() { // Implement this method return null; } @Override public void add(Integer t) { // Implement this method } @Override public Integer poll() { // ArrayList does not require this method return null; } @Override public Integer peek() { // ArrayList does not require this method return null; } }
Видите ли вы проблему , несмотря на то, что вам не требуются методы poll и peek в ArrayList, мы их реализовали. Правильным решением вышеуказанной проблемы будет: Создайте другой интерфейс с именем Deque, который будет иметь метод peek и poll.
package org.arpit.java2blog; public interface Deque{ public T poll(); public T peek(); }
И удалите просмотр и опрос из интерфейса списка.
package org.arpit.java2blog; public interface List{ public T get(); public void add(T t); }
Давайте теперь изменим класс LinkedList.
package org.arpit.java2blog; public class LinkedList implements List,Deque { @Override public Integer get() { // Implement this method return null; } @Override public void add(Integer t) { // Implement this method } @Override public Integer poll() { // Implement this method return null; } @Override public Integer peek() { // Implement this method return null; } }
Давайте теперь изменим класс ArrayList.
package org.arpit.java2blog; public class ArrayList implements List{ @Override public Integer get() { // Implement this method return null; } @Override public void add(Integer t) { // Implement this method } }
Как вы можете видеть, мы разделили два интерфейса для достижения требуемой функциональности.
Принцип Инверсии зависимостей
Согласно этому принципу инверсии зависимостей, сущности должны зависеть только от абстракций, но не от конкретизации. Согласно ему, высокоуровневый модуль никогда не должен полагаться на какой-либо низкоуровневый модуль, но должен зависеть от абстракций. Давайте еще раз разберемся в этом на другом практическом примере.
Вы идете в местный магазин, чтобы что-то купить, и решаете заплатить за это с помощью своей дебетовой карты. Итак, когда вы отдаете свою карту клерку для совершения платежа, клерк не утруждает себя проверкой того, какую карту вы дали. Даже если вы дали карту Visa, он не выставит автомат Visa для снятия вашей карты. Тип кредитной или дебетовой карты, которая у вас есть для оплаты, даже не имеет значения; они просто проведут по ней пальцем. Итак, в этом примере вы можете видеть, что и вы, и клерк зависите от абстракции кредитной карты, и вас не беспокоят особенности карты. Это и есть принцип инверсии зависимостей.
заворачивать
Я надеюсь, что теперь вы знаете основное определение всех пяти компонентов S.O.L.I.D, которые являются принципом единой ответственности, открытым, закрытым принципом, принципом замещения Лискова, принципом разделения интерфейса и инверсией зависимостей. Итак, в принципе, всякий раз, когда вы пишете код, вы должны помнить об этих основных принципах, и на самом деле, честно говоря, вы должны использовать эти принципы в качестве базовой карты при написании этих кодов, чтобы сделать их эффективными и действенными.
Управление кодом, написанным с использованием этих принципов, также является простой задачей. Использование этого принципа на начальном этапе в вашем кодировании может показаться странным, но вам нужно попрактиковаться в написании своих кодов с использованием этих принципов, и постепенно это станет частью вас. И затем написанный вами код может быть легко изменен, расширен, переработан или протестирован без каких-либо проблем в соответствии с требованиями, которым вы соответствуете. Поэтому практикуйте этот принцип, когда это возможно, чтобы улучшить ваше кодирование. Источник: Твердые принципы в Ява
Вам также может понравиться: xms и параметр xmx в java Java достигла конца файла во время синтаксического анализа Исключение NumberFormatException в java Исключение FileNotFoundException в java Проверьте, является ли число числовым в java
Оригинал: “https://dev.to/arpitmandliya/a-guide-to-solid-principles-in-java-17ne”