Как один из вариантов, зачем нужны интерфейсы - 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Или есть методы лучше?Конечно есть. Создать свой проджект айтем с куском нужного кода, и не заниматься копипастой.
Я пока нашёл только такие способы:

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

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

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