почему рекомендуется определять сервисный контракт как интерфейс - PullRequest
10 голосов
/ 02 апреля 2010

почему рекомендуется определять сервисный контракт как интерфейс. Есть ли какие-то особые преимущества по сравнению с их классами?

Ответы [ 3 ]

13 голосов
/ 02 апреля 2010

Основной целью является отдельное определение вашего сервиса от реализации

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

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

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

6 голосов
/ 02 апреля 2010

Конечно [есть несколько преимуществ]!

Основным, вероятно, является возможность реализации нескольких классов, которые поддерживают указанный интерфейс, и использование этих классов взаимозаменяемо [в отношении конкретного интерфейса] , Одним из непосредственных применений этого является использование классов Mock для тестирования; Это также используется с шаблоном IoC (Inversion of Control), и в более общем смысле, где бы мы ни заботились о «Что», а не о «Кто», т. Е. Важно то, что какой бы класс ни находился на месте, он ведет себя согласно контракту (API) ) независимо от того, «кто» (какой класс) это.

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

В двух словах (и некоторых других ответах, начавшихся с этого), Интерфейс определяет контракт и класс (ы) реализуют его (его) .
Технически, один класс мог бы выполнять обе эти вещи, т.е. вам не нужно ___ иметь интерфейсы, но очень предпочтительно определять API для почти любого поведения, которое может быть реализовано несколькими классами (будь то множественные реализации почти одного и того же) как с «фиктивными классами» или очень разными классами, но предоставляющими одну конкретную универсальную услугу / функцию, как, скажем, два очень разных Списка.)

1 голос
/ 02 апреля 2010

Поскольку интерфейс - это контракт, а класс - это средство для выполнения контракта. Существует много разных способов выполнения контракта в зависимости от контекста, поэтому имеет смысл иметь контракты как интерфейсы. которые могут иметь разные реализации

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