Возможный дубликат:
Как узнать, когда создавать интерфейс?
Мне интересно, как использовать интерфейс.
Используете ли вы интерфейсы? Если да, когда вы решаете использовать их, и когда вы решите НЕ использовать их?
В настоящее время у меня есть интерфейсы, определенные для моих уровней обслуживания и слоев моего репозитория, но мне интересно, не хватает ли я в других местах, где они были бы полезны.
Думаю, я просто не совсем понимаю их цель.
Интерфейсы определяют контракт. Любой класс, который реализует интерфейс, должен выполнить этот контракт. Это означает, что класс должен реализовывать методы, определенные в интерфейсе.
Интерфейс в основном говорит: "Я определяю то, что должны делать все разработчики. Мне все равно, как вы это делаете, но вы должны поддерживать эти операции, которые я указал".
Другое использование интерфейсов заключается в том, что вы можете использовать их в сигнатурах методов или определения типов, чтобы указать наиболее общий тип объекта. Например, в Java Map есть интерфейс, который реализуется другими классами, такими как HashMap или LinkedHashMap. Оба HashMap и LinkedHashMap по существу относятся к типу Map. Они реализуют одни и те же методы, но выполняют разные вещи (LinkedHashMap сохраняет порядок вставки).
Рассмотрим ситуацию, когда у вас есть метод, который принимает карты. Если у вас нет интерфейсов, вам нужно будет указать метод для каждого типа карты. В самом деле, вы можете сделать это с помощью перегруженных методов, но этот подход не очень хорош. Лучший способ - указать тип аргумента метода как Map. Тогда любой класс, реализующий Map, может быть передан методу. Таким образом, вам не нужно указывать метод для каждого типа карты, а также вы не ограничиваете человека, который использует ваш метод, для конкретных реализаций карты.
Интерфейс также гарантирует, что указанная функциональность присутствует в классах реализации. Таким образом, он также предоставляет стандартный способ доступа к этой функциональности. Интерфейсы также полезны при разработке API (таким образом вы можете указать стандартный интерфейс для вещей, которые вы хотите открыть).
Другим преимуществом интерфейсов является то, что он упрощает рефакторинг. Скажем, что вы хотите отключить реализацию какого-то объекта. Объект может быть аргументом метода или может быть свойством класса. Поскольку вы ввели этот аргумент или объект в качестве интерфейса, вы можете просто создать новый класс, который реализует интерфейс и передает этот класс. Поскольку вы использовали интерфейс, вы не делали дополнительных предположений относительно деталей класса. Интерфейс абстрагирует детали реализации класса, который вы используете. Таким образом, вы не делаете предположений, которые делают ваш код слишком тесно связан с конкретной реализацией.
Подводя итог, интерфейсы касаются абстракции и контрактов. С абстракцией вы скрываете основные детали и раскрываете только минимальный минимум, который вам нужно выставить. Таким образом, человек, который использует ваш класс или интерфейс, не обременен деталями реализации. Вся эта информация аккуратно скрыта внутри определенного класса, который реализует интерфейс. Контракт обеспечивает стандартизацию по всем направлениям; человек, который использует интерфейс, уверен, что все классы, реализующие интерфейс, выставляют одни и те же методы.
Интерфейс предназначен для того, чтобы рассказывать другим, что класс что-то делает.
например. Если у вас есть класс SoccerPlayer, который реализует IInjurable - вы знаете из первой строки кода класса, экземпляр SoccerPlayer знает, что делать, когда он получил травму (вы, вероятно, знали это сразу после дефиса).
Теперь рассмотрим, что реализовано IEnumerable, IQueryable или IDisposable расскажет вам об объекте и о том, что ничего не знает о самой реализации.
Кажется, очень много.
Интерфейс подобен списку правил. Вы определяете требования к классу, и для любого класса, который реализует этот интерфейс, вы знаете, что они будут следовать этим правилам. Вы можете использовать эти классы в качестве этого типа интерфейса и работать с ними, зная, что у них есть методы, свойства и события, которые вы решили.
Некоторые важные интерфейсы в ASP.Net:
Недавно я создал свой собственный интерфейс, когда хотел убедиться, что все классы, которые использовались для определенной цели, имеют определенный метод и событие. Зная это, я мог бы сначала проверить, что он реализует интерфейс, отбрасывая его и проверяя:
IMyInterface myinterface = myclass as IMyInterface;
if (myinterface == null)
{
//did NOT implement the interface
}
else
{
//did implement the interface
//call the method we KNOW is there.
myinterface.MyMethod(myparemeter);
}
В одной точке многие другие ошибки пропускают то, что интерфейсы допускают очень ограниченную форму множественного наследования, поскольку два или более несвязанных класса могут реализовывать общий интерфейс, а код может принимать объекты, которые реализуют этот интерфейс, не обращая внимания ни на что другое их тип. В противном случае единственным способом для кода принимать несколько типов объектов и использовать любую общую функциональность было бы для всех, чтобы они выходили из общего базового типа, который сам реализовал такую функциональность.
Как говорили другие, интерфейс определяет контракт, который может быть реализован классами и структурами. Это позволяет интерфейсам, таким как наследование объектов, включить полиморфизм.
Однако внедрение интерфейса отличается от наследования от объекта в том, что
Итак, в общем интерфейсы хороши, если вы хотите полиморфизм, и вы хотите его для
Стандартные примеры являются IDisposable, IComparable и IEnumerable и показывают наиболее очевидные применения.
Некоторые вещи, которые следует избегать, - это интерфейсы маркеров (интерфейсы без методов) и интерфейсы, которые не поддерживаются. По системе. например У вас есть IPost, BasePost, вопрос, ответ и комментарий, но система использует BasePost.