В чем суть принципа разделения интерфейса?

Question

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

Answer 1

Интернет-провайдер утверждает, что:

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

Интернет-провайдер имеет отношение к важным характеристикам - сплоченность и связь.
В идеале ваши компоненты должны быть тщательно адаптированы.Это повышает надежность и удобство сопровождения кода.

Обеспечение соблюдения требований ISP дает вам следующие бонусы:

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

public interface Reportable {

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


}

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

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

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

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

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

Answer 6

Интернет-провайдер это важно.

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

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

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

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

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

Предположим, у нас есть три класса: 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.Интернет-провайдер занимается классами, которые зависеть на интерфейсах, а не на классах, которые осуществлять интерфейсы.

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

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

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

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

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

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