Принцип единственной ответственности: класс, только одна причина, которая вызывает его изменения.
Зачем нужен принцип единственной ответственности?
Если у класса есть несколько причин для его изменения, то изменение функции может вызвать ошибки для других функций, поэтому лучше всего иметь только одну ответственность за класс. Но это все еще трудно достичь в практических приложениях, поэтому мы можем только стараться изо всех сил, чтобы соблюдать этот принцип.
Иногда у разработчиков возникают некоторые проблемы при разработке интерфейсов, таких как свойства пользователя и поведение пользователя, которое объявляются в интерфейсе. Это приводит к созданию бизнес -объекта и бизнес -логики, что приводит к тому, что интерфейс имеет две обязанности. Обязанности по интерфейсу неясны, и, согласно определению SRP, он нарушает принцип единых обязанностей раздела.
Вот пример:
пакет com.loulijun.chapter1; публичный интерфейс itutu {// высота void setshengao (двойная высота); двойной getshengao (); // Вес void settizhong (двойной вес); двойной gettizhong (); // есть логический чифан (логический голод); // в Интернете логический Шангванг (логический глупый); }Приведенный выше пример имеет эту проблему. Высота и вес принадлежат бизнес -объекту, и соответствующий метод отвечает в основном за атрибуты пользователя. Еда и серфинг в Интернете являются соответствующей бизнес -логикой, которая в основном отвечает за поведение пользователя. Но это даст людям ощущение, что они не знают, что делает этот интерфейс, обязанности не ясны, и различные проблемы также будут вызваны во время последующего обслуживания.
Решение: принцип единой ответственности, разбил этот интерфейс на два интерфейса с различными обязанностями.
Itutubo.java: Отвечает за атрибуты пачки (пачка, если это личное имя)
пакет com.loulijun.chapter1; /*** BO: Бизнес -объект, бизнес -объект* Отвечает за атрибуты пользователя* @author Administrator**/Public Interface itutubo {// высота void setshengao (двойная высота); двойной getshengao (); // Вес void settizhong (двойной вес); двойной gettizhong (); }Itutubl.java: ответственность за размещение
пакет com.loulijun.chapter1; /*** BL: Бизнес -логика, бизнес -логика* Отвечает за поведение пользователя* @Author Administrator**/Public Interface itUtubl {// съесть логический блюдо еду (логический голод); // развлечение логическое Шангванг (логический глупый); }Это реализует единственную ответственность за интерфейс. Затем при реализации интерфейса есть два разных класса
Tutubo.java
пакет com.loulijun.chapter1; открытый класс Tutubo реализует itutubo {private Double Height; частный двойной вес; @Override public double getshengao () {return height; } @Override public double getTizhong () {return Weight; } @Override public void setshengao (двойная высота) {this.height = height; } @Override public void settizhong (двойной вес) {this.weight = вес; }}Tutubl.java
пакет com.loulijun.chapter1; публичный класс Tutubl реализует itutubl {@Override public boolean chifan (boolean undia ulowd) {if (undwarry) {System.out.println ("Перейти, чтобы иметь горячий горшок ..."); вернуть истину; } вернуть false; } @Override public boolean shangwang (boolean глупо) {if (глупо) {System.out.println ("Так скучно, перейти в Интернет ..."); вернуть истину; } вернуть false; }}Это дает понять. Когда вам нужно изменить атрибуты пользователя, вам нужно только изменить интерфейс iTutubo, который повлияет только на класс Tutubo и не повлияет на другие классы.
Суммировать:
1. Фактическая ситуация заключается в том, что много раз мы не можем предвидеть «причину изменения» заранее, поэтому мы можем построить наш интерфейс только на основе опыта и попытаться обеспечить, чтобы у одного интерфейса была только одна ответственность. Здесь мы говорим, это интерфейсы. Занятия могут наследовать и реализовать несколько интерфейсов, что затрудняет достижение единой ответственности.
2. Когда у классов, которые я написал ранее, были несколько причин для изменений, лучше всего рефактор.
Тем не менее, есть проблема с принципом использования единственной ответственности. Нет четкого стандарта деления для «обязанностей». Если обязанности будут разделены слишком подробно, это приведет к резкому увеличению количества интерфейсов и классов реализации, что увеличит сложность и уменьшит обслуживание кода. Поэтому, используя эту ответственность, мы также должны проанализировать конкретную ситуацию. Предполагается, что интерфейс должен принять принцип единственной ответственности и максимально реализовать принцип единственной ответственности при разработке класса. Лучше всего вызвать изменения в классе, если одна из причин.