Как один из вариантов, зачем нужны интерфейсы - http://msdn.microsoft.com/en-us/magazine/cc337885.aspx (если на английском разметка кода вся "в кучу" - перейди на русский). В частности

авторDependency Inversion

You can decouple your higher-level component, InvoiceService, from its lower-level dependencies by interacting with your dependencies via interfaces rather than their concrete classes:

Правда, стоит сказать, что инвесию можно получить и через базовые классы (через абстрактные базовые классы). Но это я в качестве примера же привёл.

Где-то в степиNechto,
На самом деле, про интерфейсы столько замысловатых повествований в сети и в учебниках, и что бы вдуплиться
не один день уйдет у новичка.
Вообще то с интерфейсами все просто, у нас запрещено множественное наследование в коде пользователя.
то есть, Вы без труда можете отнаследоваться от абстрактного класса, а от двух? не получится.
Вот тут и создатели пошли на такую хитрость, второй и последующие абстрактные классы они заменили словом интерфейс.
а в самих классах убрали методы с реализацией и конструктор, оставив только абстрактные методы.
то есть интерфейс это такой же абстрактный класс, без методов с реализацией и конструктора, ну естественно финализатор там никто не видел, не верите, откройте байт код и посмотрите, то есть им там можно, множественные наследования, а нам нельзя.Хм...
Если нет конструктора, то естественно конструктор этого абстрактного класса и не будет задействован с стеке вызовов конструкторов
и все увянет на последнем вызове конструктора объекта ( мы говорим про ссылочные типы)
Хотя можно и создать объект и без вызова конструктора
По второму, я согласен с вами ( хотя фильм не смотрел) можно и было бы запихнуть и в базовый класс..
Но бываю в жизни и такие моменты, когда нужно реализовывать И.
например foreach требует что бы левый элемент реализовывал IEnumerable
Ну уж если пошел разговор о IEnumerable
Вспомним про IDisposable вы то его никуда не запихнете в базовый класс.
У вас тогда не встанет директива using
да бог с ней, у вас и не вызовется автовызов исполнения этого интерфейса.
ну не используя using вы додавите Dispose() через базовый класс.
А в другом случае ( вообще два случая авто вызова ( классических)IDisposable )
вообще никакой эрекции не будет..
Как то так..
Жопа с интерфейсами (а точнее, с наследованием в C#) в том, что, если мне нужно унаследовать реализацию , а не сигнатуру, то придётся городить длинный хвост наследования "по штучке" из классов. Либо копипастить реализацию интерфейсов из тех классов, в которых находится нужная мне. Или есть методы лучше?

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

user7320Жопа с интерфейсами (а точнее, с наследованием в C#) в том, что, если мне нужно унаследовать реализацию , а не сигнатуру, то придётся городить длинный хвост наследования "по штучке" из классов. Либо копипастить реализацию интерфейсов из тех классов, в которых находится нужная мне. Или есть методы лучше?
Ну или заниматься "внедрением зависимостей".

Antonariyuser7320Жопа с интерфейсами (а точнее, с наследованием в C#) в том, что, если мне нужно унаследовать реализацию , а не сигнатуру, то придётся городить длинный хвост наследования "по штучке" из классов. Либо копипастить реализацию интерфейсов из тех классов, в которых находится нужная мне.Это не "жопа с интерфейсами", они тут вообще ни при чем. Отсутствие множественного наследования это "жопа языка" и "жопа компилятора". А интерфейсы как костыль помогают сделать вид, что оно есть.

И да, мне множественного наследования тоже не хватает.

user7320Или есть методы лучше?Конечно есть. Создать свой проджект айтем с куском нужного кода, и не заниматься копипастой.
Я пока нашёл только такие способы:

- внедрение зависимостей (например, передаём нужный объект в конструктор);

- хелперы на статических методах (которым нужен свой статический класс).

Минус первого метода - нужно где-то инстанцировать внедряемый объект вне объекта, в который внедряем. Т. е. нужен третий объект.

Nechto

// Какой же смысл нагромождать код. Я вообще изначально представлял, что интерфейсы это как содержание книги. Обратись по оглавлению и ты получишь текст параграфа. Оказалось что я неправильно думал, и как оказалось интерфейс содержание пустышка. По которому ты не имеешь линков на методы. :(

// Зачем нужен этот весь код, приведите пожалуйста хоть кто ни будь наглядный код. Чтобы развеять мои сомнения на счёт интерфейсов.


Все эти интерфейсы, инекции и прочая муть нужны для управления сложными приложениями. Люди, которые в жизни никогда сложнее Hello World и говносайтов-визиток на ПХП ничего не писали - им трудно понять, зачем столько сложностей. Ведь можно тупо наговнокодить лапши и это будет как-то работать.

VIT2708Интерфейсы вообще не обязательно использовать. Если вы выстроили себе модель наследования обьектов то вам и не нужно создавать интерфейсы
Представляю, как выглядел бы .NET, не будь там интерфейсов, а только одиночное наследование - весь такой на хелперах-расширениях и на внедрениях. Тогда бы новички точно бы не стали такое изучать.

Nechto

Попробуйте написать небольшое приложение. Потом добавить функциональности к нему. Потом ещё добавить. Потом ещё. Потом отрефакторить. Потом использовать какие-нибудь сторонние библиотеки. Потом изменить часть кода под изменившиеся требования. Потом отрефакторить. Потом написать под другую платформу клиент для вашего приложения. И всё это 10 раз в цикле в разных комбинациях. Когда надоест тестировать, каждый раз запуская под F5 и заполняя формы, ставить точки останова в обработчиках, вы дойдёте до юнит-тестов. Там и до инъекций недалеко. Там же будет разделение кода представлений и моделей. И т. д. и т. п. Объяснять неопытному новичку - почти гиблое дело. Он просто не поймёт. Нужна практика. Очень много практики. Грубо говоря, 10 лет по 4-8 часов в день чистого программирования.

Ох уже эти Фаулеры...

http://en.wikipedia.org/wiki/Factory_pattern More broadly, a subroutine that returns a "new" object may be referred to as a "factory"

Фаулер от спорта и биологии, при собеседовании кандидата на игру в футбол:

автор- Вы обладаете навыками асимметричной наземной локомоции?

- Нет, я только умею бе... (бегать)

- "Бее", "мее" - вот всё, что вы знаете, жалкие джуниоры. Нам такие не нужны. Мы ищем настоящих профи, типа меня (напыщенного 23-летнего "сеньора", наблатыкавшегося умными терминами, значения которых он и сам до конца не знает).

Назови какую-нибудь банальную и привычную фигню как-нибудь заумно. Напиши об этой простой фигне кучу книжек, чтобы никто не мог понять, про что там. - Получи всемирное признание и известность, как профессор "словоблудия" и маститый исследователь этой фигни.

Особенно смешно, когда отвечаешь "фабрика - это, в общем случае, такая штука, которая создаёт новый объект". А в ответ "нууу... не совсем". Думаешь так про себя: "боже, что этот болванчик ещё имел ввиду - понавбивают себе в голову каждый своё видение, а потом попробуй поподстраивайся под них".

ИзопропилRubinDmПонять бы еще, зачем оно надо? :/


какой GetEnumerator должен звать foreach(var v in new A()) ?
А что, если я возьму и на собеседовании при подобном вопросе вдруг неожиданно вылью на тебя заранее заготовленное ведро помоев? "Нифига себе!", - подумает собеседующий, - "у этого парня очень нестандартное мышление. Он явно сможет найти выход из любой ситации. Берём его в креативный отдел главных архитекторов!"

Не в обиду, а так... )))

Сон Веры Павловныuser7320Не в обиду, а так... )))
Эмм.. а ведь вроде как никто никого лично в незнании вопроса про энумератор не обвинял ;)
Так я же не в обиду, а так... Извините, кого что если...