Принцип разделения интерфейсов (ISP) гласит, что класс не должен быть вынужден реализовывать интерфейсы, которые он не использует. Другими словами, класс должен иметь конкретный и целенаправленный интерфейс, включающий только те методы, которые имеют отношение к его поведению.
Полное теоретическое объяснение этого принципа я задокументировал в своей предыдущей статье под названием Принцип разделения интерфейса: I в SOLID — Теория. Вы можете получить к нему доступ, чтобы изучить теоретическую сторону.
В этой статье я расскажу о практической части. Код за кодом и построчно.
Какова связь между этим и принципом разделения интерфейса?
Мира и Эки — спортсмены одного класса. Мира — пловчиха, а Эки — бегун. Как спортсмены, они оба знают, что упражнения и практика необходимы. Их подготовка разная: Мира сосредоточится на упражнениях по плаванию, а Эки - на беговых упражнениях. Однако есть у них одно сходство: они оба растягиваются перед началом тренировки.
В программировании есть термин «Интерфейс». Интерфейс подобен контракту, который должен выполнить класс. Итак, мы можем связать, что существует интерфейс Athlete с контрактом, содержащим существующие упражнения.
Затем есть класс Runner, представляющий бегуна, и класс Swimmer, представляющий пловца. Оба они реализуют интерфейс Athlete.
Проблема этой реализации в том, что она неэффективна и неточна. Несмотря на то, что Бегун действительно бегает и разминается, это не означает, что его можно объединить с Пловцом, который плавает и разминается, в одном интерфейсе.
Чтобы это исправить, нам нужно реализовать принцип разделения интерфейса. Принцип разделения интерфейсов гласит, что класс не должен быть вынужден реализовывать интерфейсы, которые он не использует.
Плавание – это категория водного спорта. Все водные виды спорта требуют плавания, поэтому имеет смысл создать такой интерфейс. То же самое и с бегуном, который представляет собой наземный вид спорта, требующий бега. Мы можем создать два новых интерфейса: интерфейс наземного спорта и интерфейс водного спорта. Класс Runner будет включать методы run() и WarmUp(), а класс Swimmer — методы swim() и WarmUp().
Как это применяется в реальном случае разработки программного обеспечения?
Приложение для управления библиотекой должно отслеживать книги, журналы и газеты. Все их можно взять напрокат, кроме газет. Давайте начнем с разработки интерфейса под названием LibraryItemInterface, который можно будет заимствовать, вернуть и прочитать на месте.
Книги, журналы и газеты будут классами, реализующими этот интерфейс.
Проект нарушает принцип разделения интерфейсов (ISP). Этот принцип гласит, что класс не следует заставлять реализовывать методы, которые ему не нужны. Например, газета является библиотечным предметом, но ее нельзя взять напрокат. Поэтому не следует принудительно реализовывать методы borrow() и return().
Чтобы решить эту проблему, мы можем усовершенствовать интерфейс и сделать его более конкретным. Например, мы можем создать интерфейс Readable и интерфейс Borrowable. Интерфейс Readable будет иметь метод read(), а интерфейс Borrowable будет иметь методы borrow() и return(). Таким образом, классу необходимо реализовать только те интерфейсы, которые соответствуют его функциональности.
После разделения интерфейсов классы теперь могут реализовывать те интерфейсы, которые им нужны. Book и Magazine могут брать, возвращать и читать, поэтому они реализуют интерфейсы Readable и Borrowable. Газету можно только читать, поэтому она будет реализовывать только интерфейс Readable.
Этот новый дизайн более эффективен и точен, поскольку он требует от классов только реализации тех интерфейсов, которые им действительно нужны.
Поздравляем!
Добро пожаловать в конец урока! Поздравляю с тем, что уже многому научился.
Сначала вы узнаете о принципе разделения интерфейсов (ISP), одном из принципов SOLID. ISP утверждает, что класс не следует заставлять реализовывать интерфейсы, которые он не использует.
Во-вторых, вы узнаете, как работает ISP, используя аналогию со спортсменами.
В-третьих, вы узнаете реальный пример того, как ISP реализован в программном обеспечении для управления библиотекой.
От писателя
Здравствуйте, разрешите представиться — я Мухаммад Резкий Сулихин. Мы подошли к концу этой статьи, и я искренне благодарю вас за то, что нашли время ее прочитать. Если у вас есть какие-либо вопросы или отзывы, свяжитесь со мной напрямую по электронной почте [email protected]. Я более чем рад получить ваше мнение, будь то мои навыки письма на английском языке или что-то еще, я могу ошибаться. Ваши идеи помогут мне расти.
С нетерпением ждем возможности связаться с вами в будущих статьях! Кстати, я мобильный разработчик, сейчас учусь в Apple Developer Academy. Я открыт для различных возможностей, таких как сотрудничество, внештатная работа, стажировки, неполный или полный рабочий день. Для меня было бы огромным счастьем изучить эти возможности.
