[oop] интерфейсы

state7401281

когда имеет смысл использовать интерфейсы?
какие это дает преимущества по сравнению с классами?

state7401281

дайте какой-нибудь пример использования интерфесов

Dasar

когда имеет смысл использовать интерфейсы?
когда есть полиморфизм
какие это дает преимущества по сравнению с классами?
поддержку полиморфизма, классы не поддерживают полиморфизм полностью

Dasar

дайте какой-нибудь пример использования интерфесов


void Output(IEnumerable<int> items)
{
foreach (var item in items)
Console.WriteLine(item);
}
IEnumerable<int> Generate(int min, int max)
{
for (int i = min; i < max; ++i)
yield return i;
}

var list = new List<int>
var dictionary = new Dictionary<int, int>
var myCollection = new MyCollection<int>
Output(list);
Output(dictionary.Keys);
Output(dictionary.Values);
Output(myCollection);
Output(Generate(10, 100;

state7401281

примерно понял, спасибо

kruzer25

ИМХО, когда нужно сделать класс, который будет реализовывать сразу несколько интерфейсов, или когда ты уверен, что между разными реализациями интерфейса не будет вообще ничего общего (хотя вряд ли можно быть в этом уверенным).
Иначе - лучше пользоваться абстрактными классами.

timefim

>классы не поддерживают полиморфизм полностью
Плюсы получается недополиморфизмны?

kokoc88

>классы не поддерживают полиморфизм полностью
Плюсы получается недополиморфизмны?
Может быть, имелись в виду неабстрактные классы.

sylar

по-моему скромному мнению интерфейсы стоит использовать в таких общих случаях:
0) сопряжение различных частей системы - определяете интерфейсы взаимодействия, каждая группа колбасит свою часть ( + в теории параллельно пишутся тесты на определение конформности (тестерами) исходя из этих интерфейсов )
и определяете интерфейсы объектов которыми обмениваетесь в процессе взаимодействия.
1) для подключаемых компонент - по-моему достаточно значимое преимущество. классы для такого использования недостаточно полиморфны.
(см. например статьи про IoC: здесь )
p.s.: лично я сейчас пришел к тому что классы делать просто контейнерами полей - т.е. без методов, методы все выносить в хелперы (т.е. четкое разделение данных и их обработки).
соответственно класс реализует какой-то интерфейс (или несколько, как напроектировал).

Dasar

Плюсы получается недополиморфизмны?
интерфейсы в C++ есть, только в коде записываются как abstract class.

kruzer25

А в плюсах есть множественное наследование?

mkrec

вопрос похож на издевательский.

kruzer25

Нет, я просто действительно не в курсе.

Dasar

> А в плюсах есть множественное наследование?
плюсы - один из небольшого числа языков, которые поддерживают множественное наследование не только на уровне интерфейсов, но и на уровне реализаций(на уровне классов)

6yrop

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

bleyman

а можно подробнее пояснить?
Может, имелась в виду известная проблема наследования Круга и Эллипса?
Типа что круг является частным случаем эллипса для методов, читающих параметры, но эллипс является частным случаем круга для методов, изменяющих параметры (обратное в обоих случаях неверно). Поэтому прямо отнаследовать один от другого невозможно, а разнесение функциональности на четыре интерфейса позволяет реализовать все ваши самые смелые мечты!

Dasar

а можно подробнее пояснить?
полиморфизм - умение работать с разнородными вещами одинаковым способом
интерфейс - декларация стыка без реализации
класс - декларация с реализацией
т.к. множественное наследование классов приводит к сложному коду/не поддерживается, то на классах фактически можно построить только линейную цепочку наследования: A -> B -> C
соответственно мы получим лишь частный случай полиморфизма: умение работать одинаковым способом с однородными вещами

Dmitriy82

Какой смысл ты вкладываешь в понятие "объект X является частным случаем объекта Y для таких-то методов"? Конкретно мне непонятно про методы, изменяющие параметры.
Т.е. с читающими:
эллипс: getAxisA, getAxisB
круг: getAxisA, getAsixB, getRadius.
Круг частный случай эллипса в том смысле, что множество читающих методов для эллипса включено в множество читающих методов для круга.
В случае изменяющих:
эллипс: setAxisA, setAxisB
круг: setRadius
Множества методов находятся в общем положении, никто не является ничьим частным случаем. Или подразумевается что эллипс тоже имеет метод setRadius?

Dmitriy82

Ой. В свете http://en.wikipedia.org/wiki/Circle-ellipse_problem вопрос отпал.
Оставить комментарий
Имя или ник:
Комментарий: