Что такое точно “основанное на интерфейсе программирование”?
шрифт Consolas Свободный шрифт от MS разработан для чтения кода.
7 ответов
Это в основном вопрос выражения ваших зависимостей в терминах интерфейсов, а не конкретных классов (или того хуже, статических методов). Поэтому, если одному из ваших классов необходимо выполнить аутентификацию, ему должен быть предоставлен IAuthenticator (или что-то еще).
Это означает, что:
- Вы можете написать свой код перед реализацией реальной зависимости
- Вы можете очень легко протестировать с помощью имитации (без имитации классов, что становится некрасивым)
- Понятно, от чего вы зависите в терминах API, а не в реализации (то есть у вас слабая связь)
Глава 6 «Практический дизайн API» Ярослава Тулача озаглавлена «Код против интерфейсов, а не реализации». Это объясняет, что
То, что вы называете «программированием на основе интерфейса», чаще называют программированием интерфейса. Вот пример ниже. Преимущество заключается в сокрытии фактической реализации интерфейса и обеспечении большей гибкости и упрощения поддержки кода в будущем.
YourInterface foo = CreateYourInterface();
foo.DoWork();
foo.DoMoreWork();
CreateYourInterface () вернет конкретную реализацию YourInterface. Это позволяет вам изменить функциональность приложения, изменив одну строку:
YourInterface foo = CreateYourInterface();
Если вы загуглите интерфейсы, вы найдете много информации о том, насколько полезными могут быть интерфейсы.
Идея состоит в том, чтобы определить четкие интерфейсы, которые будут использоваться различными компонентами / частями / классы / модули для общения и взаимодействия. После того, как вы определили, каким должен быть ввод / вывод этих интерфейсов, вы можете позволить различным командам разработать все необходимое для выполнения требований интерфейса, включая тестирование ввода / вывода и т. Д.
Если вы будете следовать этому По шаблону, различные команды могут начать разработку своей части, не дожидаясь готовности других частей. В дополнение к этому вы можете использовать модульное тестирование (использование поддельных объектов для моделирования других частей, которые вы не разрабатываете, и тестирования своей части).
Посмотрим, помогут ли эти очень популярные обсуждения:
Зачем мне использовать интерфейсы?
Когда следует использовать интерфейсы?
Программирование на основе интерфейсов можно рассматривать как разделение реализации функциональности и способа доступа к ней.
Вы определяете интерфейс
interface ICallSomeone {
public bool DialNumber (номер строки);
}
и вы пишете свою реализацию
public class callsomeone: ICallSomeone {
public bool DialNumber (номер строки) {
// набираете номер, возвращаете результаты
}}
Вы используете интерфейс, не заботясь о реализации. Если вы измените реализацию, ничего не изменится, потому что она просто использует интерфейс.
Это то, что я не рекомендую активно использовать при разработке на C #.
Интерфейсное программирование в основном представляет собой программирование интерфейсов. Вы разрабатываете интерфейсы, которые собираетесь использовать в контрактах, а фактическая реализация интерфейсов скрыта за этими контрактами.
Это было очень распространено до .NET, поскольку лучший способ получить повторно используемые компоненты в Windows был через COM, который везде работал через интерфейсы. Однако, учитывая способность .NET поддерживать несколько языков в единой среде выполнения (CLR), а также превосходную поддержку управления версиями по сравнению с машинным кодом, полезность программирования на основе интерфейса резко снижается, когда вы программируете на C # ( если вы не пытаетесь создать компоненты COM, в этом случае вы