Псевдомножественное наследование с дополнительными методами в интерфейсах в C#?

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

Скажем, я есть метод, который принимает объект типа IBar. Если я реализую интерфейс IBar в классе Foo с помощью методов расширения, то Foo не является производным от IBar и не может использоваться взаимозаменяемо с ним (принцип подстановки Лискова). Конечно, я получаю поведение, которое хочу добавить в Foo, но я теряю самый важный аспект создания интерфейсов в первую очередь - возможность определять абстрактный контракт, который может быть реализован различными способами различными классами, чтобы зависимым классам не обязательно знать о конкретных реализациях.

Если мне нужно множественное наследование (а пока я '

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

Интерфейс объявляет: «Я забочусь об использовании этой функции, но не о том, как она выполняется». Это оставляет разработчикам свободу выбора как. Он отделяет намерение, общедоступный API, от механизма, класса с конкретным кодом.

Поскольку это основное преимущество интерфейсов, реализация их полностью как методов расширения, кажется, противоречит их цели. Даже IEnumerable имеет метод экземпляра.

Edit : Кроме того, объекты предназначены для воздействия на данные, которые они содержат. Методы расширения могут видеть только общедоступный API объекта (поскольку это просто статические методы); вам придется раскрыть все состояние объекта, чтобы он заработал (объектно-ориентированный запрет).