Из Википедии:
Принцип единой ответственности гласит, что у каждого класса должна быть единственная ответственность, и эта ответственность должна быть полностью инкапсулирована классом.
Означает ли это, что реализация нескольких интерфейсов нарушает этот принцип?
Я бы сказал, не сам по себе. У класса может быть одна ответственность, но он может выполнять несколько задач в процессе и реализовывать один интерфейс для каждого набора действий, которые ему необходимо выполнять для выполнения своих обязанностей.
Кроме того, интерфейсы в Java могут использоваться, чтобы говорить о том, какие свойства имеет класс (например, Comparable и Serializable), но на самом деле ничего не говорить об ответственности класса.
Однако, если класс реализует несколько интерфейсов, каждый из которых соответствует одной ответственности, тогда это будет нарушением этого принципа.
Может быть, но не обязательно.
Интерфейс - это не ответственность. Существует очень мощный режим архитектуры, который рассматривает интерфейсы как определяющие роль, которую объект может играть в приложении.
Подумайте, что это значит. У вас может быть класс Person со всеми видами интерфейсов (давайте использовать соглашение .net для именования)
class Person : IAmAStudent, IDrawSocialSecurity, IAmACitizen {
public SocialSecurityNumber getSocialSecurityNumber() {
return this.ssn;
}
private SocialSecurityNumber ssn;
public Person(SocialSecurityNumber ssn) { this.ssn = ssn; }
}
Очевидно, что это не может нарушать SRP. Очевидно, что у него только одна причина для изменений - если отношения между людьми и номерами социального страхования меняются. Тем не менее, объект реализует множество интерфейсов и играет несколько ролей в приложении.
Теперь, если вы реализуете несколько интерфейсов, которые предоставляют разные функциональные возможности, вы можете нарушать SRP, но это также может быть своего рода требованием к суждению. Принцип единственной ответственности - отличное практическое правило для достижения слабой связи, но это не единственный идеал в городе. Также существует высокая степень согласованности, согласно которой связанный код должен существовать вместе. Эти два понятия принципиально расходятся (хотя часто есть способы добиться хорошего баланса). Таким образом, вы можете сделать разумный выбор в пользу одного над другим и сознательно решить нарушить SRP.
В конечном счете, SRP и все правила SOLID в большей степени направлены на то, чтобы вы думали в соответствии с определенными направлениями, а не на то, чтобы вы каждый раз слепо им следовали.
«Единая ответственность» зависит от уровня абстракции. Например, сложная система, если рассматривать ее на системном уровне, может иметь одну ответственность. Например, телевизионная система отвечает за показ видеоизображения. На следующем, более низком уровне, эта система состоит из подсистем, монитора, блока питания и т. Д. На этом уровне у каждого из этих блоков есть свои собственные обязанности.
Точно так же класс на одном уровне может считаться несущим единственную ответственность. Но на более низком уровне он может иметь другие составляющие модули (классы, интерфейсы и т. Д.), Которые выполняют части его работы. Например, обязанность класса Student - представить абстракцию учащегося. Однако в нем может быть другая единица (класс), представляющая адрес студента.
Таким образом, использование нескольких интерфейсов само по себе не нарушает объектно-ориентированных принципов.
