почему рекомендуется определить контракт на обслуживание как интерфейс
почему рекомендуется определить контракт на обслуживание как интерфейс. Какие-либо определенные преимущества перед наличием их как классы?
3 ответа
Основная цель - отдельное определение вашей службы от реализации
Пользователь вашей службы не должен ничего знать о том, как вы реализовали ваша служба, но он должен знать, какие операции он может делать и как.
Вот почему он использует интерфейс вместо класса, потому что интерфейс не содержит реализации.
Вы можете поделиться своим интерфейсом один раз и не беспокоиться годами, даже если вы меняете реализацию его методов каждый день. Конечным пользователям не нужно перекомпилировать код, использующий вашу службу
Конечно [есть несколько преимуществ]!
Основным из них, вероятно, является возможность реализовать несколько классов, которые поддерживают упомянутый интерфейс, и использовать эти классы взаимозаменяемо [в отношении конкретного интерфейса]. Одно из непосредственных применений этого - с Mock-классами, используемыми для тестирования; Это также используется с шаблоном IoC (Inversion of Control), и в более общем случае, когда мы заботимся о «Что», а не о «Кто», то есть важно то, что какой бы класс ни был на месте, он ведет себя в соответствии с контрактом (API ) независимо от того, "кто" (какой класс) это.
Еще одно существенное преимущество интерфейсов - это способность модулировать поведение .Например, ваше приложение может реализовывать концепцию, которая работает, скажем, как список (может повторяться, предоставляет ряд элементов и т. Д.) и как валидатор виджетов (некоторая специфическая вещь для приложения). Имея два интерфейса, «описывающих» этот конкретный объект, вы можете использовать экземпляры этого класса везде, где бы вы ни использовали List (и только он), и аналогичным образом вы можете использовать его как валидатор виджетов (и просто так) везде, где этот валидатор необходим. . Это похоже на множественное наследование, но более гибкое.
В двух словах (и некоторые другие ответы начинались с этого), Интерфейс определяет контракт, а Класс (ы) реализуют его .
Технически один класс мог бы делать обе эти вещи, т.е. вам не __ нужно __ иметь интерфейсы, но очень предпочтительно определять API для большинства любого поведения, которое может быть реализовано несколькими классами ( будь то несколько реализаций почти одного и того же, как с «фиктивными классами», или очень разных классов, но предоставляющих одну конкретную общую услугу / функцию, например, два очень разных списка.)
Поскольку интерфейс ЯВЛЯЕТСЯ контрактом, а класс - это средство выполнения контракта. В зависимости от контекста может быть много разных способов выполнения контракта, поэтому имеет смысл использовать контракты в качестве интерфейсов. которые могут иметь разные реализации