Стать старшим среди миллионов программистов!
Введение
Это четвертая статья из серии «SOLID для юной жесткой молодежи». В этой статье я расскажу о Interface Segregation Principle — принципе разделения интерфейсов.
- Принцип единой ответственности
- Открытый/закрытый принцип
- Принцип подстановки Лисков.
- Принцип разделения интерфейсов
- Принцип инверсии зависимостей
Вместо того, чтобы использовать большой интерфейс, мы должны разделить его на множество маленьких интерфейсов со многими специфическими целями.
Объясните принцип
Прежде чем объяснить принцип, я немного повторю концепцию интерфейса, чтобы вы потеряли основы.
Интерфейс — это пустой класс, содержащий объявление имени метода без объявления свойств или чего-либо еще, и эти методы также пусты. Поэтому любой класс, использующий класс интерфейса, должен определять методы, объявленные в классе интерфейса.
Чтобы спроектировать гибкую, легко изменяемую систему, модули системы должны взаимодействовать друг с другом через интерфейс. Каждый модуль будет вызывать функцию другого модуля через интерфейс, независимо от приведенной ниже реализации. Как упоминалось выше, поскольку интерфейс содержит только пустое объявление метода, когда класс реализует интерфейс, он должен реализовать все методы, объявленные в этом интерфейсе.
Это эквивалентно тому, что если мы создадим большой интерфейс (например, более 100 методов), то каждый класс должен будет реализовать все 100 методов, включая методы, которые никогда не используются. Если мы применим ISP, мы разделим этот интерфейс на множество маленьких интерфейсов; классы должны реализовать интерфейсы с нужными им функциями, нет необходимости реализовывать избыточные функции.
Пример
Это самый простой для понимания принцип SOLID; вам нужно только немного прочитать код, чтобы понять его сразу! Предположим, мы хотим написать программу, показывающую свойства животных. Любое животное может есть, пить, спать; мы проектируем интерфейс IAnimal следующим образом:
public interface IAnimal {
void Eat();
void Drink();
void Sleep();
}
public class Dog : IAnimal {
public void Eat () {}
public void Drink () {}
public void Sleep () {}
}
public class Cat : IAnimal {
public void Eat () {}
public void Drink () {}
public void Sleep () {}
}
Когда мы хотим добавить новых животных и функции, мы должны добавить в интерфейс такие методы, как плавание, полет, охота и т. д. Это приводит к тому, что интерфейс раздувается. Когда животное наследует интерфейс, оно также должно реализовывать функции, которые не используются.
На практике, когда нам нужно добавить новые функции, мы часто добавляем в интерфейс методы, в результате чего интерфейс становится больше. При добавлении методов в интерфейс IAnimal старые классы, такие как Dog и Cat, должны реализовывать новые методы, поэтому это требует времени. Решением в этой ситуации является разделение интерфейса IAnimal на небольшие интерфейсы следующим образом:
Чтобы правильно разделить большой интерфейс на маленькие интерфейсы, вам следует просмотреть первую статью из серии Принцип единой ответственности. Однако иногда разделение нескольких интерфейсов может увеличить количество интерфейсов, увеличить количество классов и рассмотреть преимущества перед применением.
Вывод
Применение принципа ISP сделает систему более гибкой при минимизации избыточного кода (из-за реализации ненужных функций). Однако на практике еще много случаев форс-мажора, что приходится создавать большой интерфейс. Например: В приложении ASP.NET, если вы хотите реализовать функцию входа/авторизации для пользователя, вы должны реализовать интерфейс MembershipProvider. Этот интерфейс довольно большой с более чем 27 методами (теперь их больше).
Возможно, цель Microsoft при разработке этого интерфейса состоит в том, чтобы охватить все необходимые функции входа/авторизации. Однако из-за этого большого интерфейса, если мы хотим сделать простую децентрализацию, то реализация этих 27 методов занимает много времени и не нужна.
использованная литература
https://www.codeproject.com/Tips/766045/Interface-Segregation-Principle-ISP-of-SOLID-in-Cs
