В чем причина принципа разделения интерфейса? - PullRequest
24 голосов
/ 12 сентября 2008

Принцип разделения интерфейса (ISP) гласит, что многие специфичные для клиента интерфейсы лучше, чем один универсальный интерфейс. Почему это важно?

Ответы [ 8 ]

31 голосов
/ 12 сентября 2008

Интернет-провайдер заявляет, что:

Клиенты не должны быть вынуждены зависеть на методы, которые они не используют.

ISP относится к важным характеристикам - сцепление и сцепление .
В идеале ваши компоненты должны быть в высшей степени адаптированы. Это повышает надежность кода и ремонтопригодность.

Принудительный провайдер дает вам следующие бонусы:

  • Высокая сплоченность - лучшая понятность, надежность
  • Низкая муфта - лучшая ремонтопригодность, высокая устойчивость к изменениям

Если вы хотите узнать больше о принципах разработки программного обеспечения, получите копию Agile Software Development, принципы, шаблоны и практики книга.

7 голосов
/ 01 августа 2013

Разделение интерфейса - это «Я» по принципу SOLID, прежде чем копать слишком глубоко с первым, давайте объясним, что означает последнее.

SOLID можно считать набором лучших практик и рекомендаций, сделанных экспертами (то есть они были доказаны ранее), чтобы обеспечить надежную основу для разработки приложений. Эти методы направлены на то, чтобы упростить поддержку, расширение, адаптацию и масштабирование наших приложений.

Почему я должен заботиться о программировании SOLID?

Прежде всего, вы должны осознать, что не навсегда останетесь там, где вы есть. Если мы используем стандарты и хорошо известные архитектуры, мы можем быть уверены, что наш код будет легко поддерживать другие разработчики, которые идут за нами, и я уверен, что вы не захотите решать задачу исправления кода, который не помог не применял ни одной известной методологии, так как это было бы очень трудно понять.

Принцип разделения интерфейса.

Знайте, что мы знаем, что такое принципы SOLID, мы можем подробнее узнать о принципе разделения интерфейса, но что именно говорит сегрегация интерфейса?

«Клиентов не следует заставлять применять ненужные методы, которые они не будут использовать »

Это означает, что иногда мы склонны создавать интерфейсы с большим количеством методов, которые могут быть хорошими в некоторой степени, однако это может легко использоваться неправильно, и мы можем получить классы, которые реализуют пустые или бесполезные методы, что, конечно, добавляет дополнительные код и нагрузка на наши приложения. Представьте, что вы объявляете множество методов в одном интерфейсе, если вам нравятся наглядные пособия, класс, реализующий интерфейс, но для которого действительно требуется пара методов, будет выглядеть следующим образом:

enter image description here

С другой стороны, если вы правильно примените сегрегацию интерфейса и разделите свой интерфейс на меньшие подмножества, вы можете быть уверены, что реализуете только те, которые необходимы:

enter image description here

См! Это намного лучше! Применение этого принципа позволит вам иметь низкое сцепление, что способствует лучшей ремонтопригодности и высокой устойчивости к изменениям. Таким образом, вы можете реально использовать использование интерфейсов и реализацию методов, когда вам это действительно нужно. Теперь давайте рассмотрим менее абстрактный пример, скажем, вы объявили интерфейс под названием Reportable

public interface Reportable {

        void printPDF();
        void printWord();
        void printExcel();
        void printPPT();
        void printHTML();


}

И у вас есть клиент, который будет экспортировать только некоторые данные в формате Excel, вы можете реализовать интерфейс, но вам нужно будет только реализовать метод Excel? Ответ - нет, вам придется кодировать реализацию для всех методов, даже если вы не собираетесь их использовать, это может привести к большому количеству ненужного кода и, следовательно, к затруднению поддержки кода.

Помните, что будьте проще и не повторяйте себя, и вы обнаружите, что уже используете этот принцип, не зная.

5 голосов
/ 12 сентября 2008

Это упрощает интерфейс, который будет использоваться любым клиентом, и удаляет зависимости, которые они могли бы развить в тех частях интерфейса, которые ему не нужны.

3 голосов
/ 13 декабря 2013

Этот принцип в первую очередь служит двойным целям

  • Чтобы сделать код более читабельным и управляемым.

  • Способствует единоличной ответственности за занятия (высокая сплоченность). Конечно, почему у класса должен быть метод, который не имеет поведенческого воздействия? Почему бы просто не удалить его. Вот что такое провайдер

Есть несколько вопросов, которые дизайнер должен задать с вопросами к провайдеру

  • Чего можно достичь с провайдером
  • Как проанализировать уже существующий код на предмет нарушений интернет-провайдера

Чтобы продолжить это обсуждение, я также должен добавить, что этот принцип не является «принципом» в самом строгом смысле этого слова, потому что при определенных обстоятельствах применение ISP к дизайну вместо повышения читабельности может сделать структуру объекта нечитаемой. и загроможден ненужным кодом. Вы можете хорошо наблюдать это в пакете java.awt.event

Больше в моем блоге: http://design -principle-pattern.blogspot.in / 2013/12 / interface-segregation-принцип.html

3 голосов
/ 12 сентября 2008

Одна из причин заключается в том, что наличие множества интерфейсов с минимальным количеством методов для каждого упрощает реализацию каждого интерфейса и их правильную реализацию. Большой интерфейс может быть неуправляемым. Кроме того, использование сфокусированного интерфейса в сценарии делает код более удобным, поскольку вы можете видеть, какой аспект объекта используется (например, интерфейс IComparable позволяет вам знать, что объект используется только для сравнения в данном сценарии).

1 голос
/ 14 октября 2016

ISP важно.

Основная идея интернет-провайдера: нельзя заставлять клиента зависеть от методов, которые он не использует.

Этот принцип кажется более логичным. В идеале клиент не должен реализовывать методы, которые не используются клиентом.

См. Ниже вопрос SE для примера кода:

Принцип разделения интерфейса - программа для интерфейса

Преимущества:

  1. Гибкость : В отсутствие ISP у вас есть один общий интерфейс FAT и множество классов, реализующих его. Предположим, что у вас было 1 интерфейс и 50 классов. В случае изменения интерфейса все 50 классов должны изменить свою реализацию.

    С провайдером вы разделите общий интерфейс FAT на мелкие гранулированные небольшие интерфейсы. Если в небольшом гранулированном интерфейсе есть изменения, это повлияет только на классы, реализующие этот интерфейс.

  2. Поддержка и простота использования : Поскольку изменения ограничены тонким гранулированным интерфейсом, а не общим интерфейсом FACT, обслуживание кода проще. Несвязанный код больше не является частью классов реализации.

0 голосов
/ 31 мая 2019

В статье Роберта Мартина по этому вопросу приводится объяснение, которое упоминается реже:

Обратная сила, приложенная клиентами к интерфейсам.

Если два класса напрямую зависят от двух разных методов третьего класса, это увеличивает вероятность того, что изменения одного из первых двух классов повлияют на другой.

Предположим, у нас есть три класса: Red, Green и Blue.

Red и Green оба зависят Blue, но каждый зависит от своего метода. Это означает, что Red зависит от одного метода Blue, но не использует другой метод. Аналогично, Green зависит от Blue, но использует только один метод, а не другой.

Нарушение принципа в Red и Green, потому что каждый зависит от класса - Blue - но не использует хотя бы один из его методов.

Какую проблему это может создать?

  • Мне нужно изменить Red, и я также изменил Blue, чтобы удовлетворить потребности Red.
  • Я не изменил конкретный метод в Blue, от которого зависит Green, но, тем не менее, Green зависит от Blue, и я изменил Blue, что все равно может повлиять на Green.
  • Следовательно, мои изменения в Red могут повлиять на Blue, потому что они привели меня к изменению класса, от которого зависят оба.

Это «обратная сила». Мы иногда меняем класс из-за потребностей своих клиентов. Если у этого класса разные клиенты, которые используют его для разных целей, мы рискуем повлиять на них.

Как уже говорилось, простое определение принципа разделения интерфейса:

ни один клиент не должен зависеть от методов, которые он не использует.

Между этим и вышеприведенным пунктом из статьи Роберта Мартина очевидно, что многие объяснения провайдера на самом деле говорят о других принципах.

  • Классы или интерфейсы с множеством методов нежелательны, но не специально из-за провайдера. Они могут нарушать Единую ответственность. Но нарушение ISP не в большом интерфейсе или большом классе - это в классах, которые зависят от от большого интерфейса, если они не используют все его методы. Если они используют все методы, это все еще звучит грязно, но это не имеет никакого отношения к провайдеру.
  • Классы, которые реализуют интерфейс, но генерируют исключения для определенных методов, являются плохими, но это также не ISP. ISP - это классы, которые зависят от интерфейсов, а не классы, которые реализуют интерфейсы.

Если мы используем «сегрегацию интерфейсов» в Google, большинство лучших результатов, включающих примеры кода, демонстрируют классы, которые не полностью реализуют интерфейсы , что не является целью ISP. Некоторые даже подтверждают принцип:

Принцип разделения интерфейсов гласит, что клиенты не должны принуждаться к реализации интерфейсов, которые они не используют

... но это не принцип. В определяющей статье упоминаются такие проблемы, как побочный эффект нарушения ISP, но указывается, что это нарушения Лискова.

Более того, каждый раз, когда новый интерфейс добавляется в базовый класс, этот интерфейс должен быть реализовано (или разрешено по умолчанию) в производных классах. Действительно, связанная практика заключается в добавлении этих интерфейсов к базовому классу в виде нулевых виртуальных функций, а не чисто виртуальных функций; в частности, чтобы производные классы не были обременены необходимостью их реализации. Как мы узнали во второй статье этого столбца, такая практика нарушает принцип замещения Лискова (LSP), приводя к проблемам с обслуживанием и возможностью повторного использования.

Более того, говорить, что клиент не должен реализовывать методы, которые он не использует, даже не имеет смысла. клиенты интерфейса не реализуют его методы.

Я не хочу напыщенно цитировать газету, как будто это священный приказ или что-то в этом роде. Но если мы собираемся использовать название принципа, описанного в статье (название самой статьи), мы должны также рассмотреть фактическое определение и объяснение, содержащиеся в этой статье.

0 голосов
/ 04 ноября 2015

Чтобы избежать попыток регрессии, когда меняется только один клиент или один клиент. Если вы объединили все свои методы поведения в одном БОЛЬШОМ интерфейсе, просто подумайте о том, как вы в конечном итоге будете тестировать все фрагменты кода, на которые ссылался только этот интерфейс, даже когда произошли только небольшие изменения.

Более подробное объяснение см. В статье Принцип разделения интерфейса

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...