Псевдо-множественное наследование с методами расширения интерфейсов в C #?

Question

Похожий вопрос, но не совсем одно и то же

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

Каковы некоторые из недостатков этого?Я думаю, плюсы довольно очевидны, а минусы обычно возвращаются, чтобы укусить вас позже.

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

Answer 1

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

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

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

Answer 2

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

Интерфейс заявляет: "Меня волнует использование этой функциональности, но не то, как это достигается". Это оставляет разработчикам свободу выбора способа.Он отделяет intent, публичный API, от механизма, класса с конкретным кодом.

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

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