Являются ли методы расширения объектно-ориентированной особенностью C #?

Question

Следуют ли методы расширения объектно-ориентированной парадигме в C #?

Полезно ли использовать методы расширения?

В жизненном цикле разработки программного обеспечения, как мы должны рассматривать этот вопрос на этапе проектирования?

Answer 1

Эрик Липперт написал об этом в блоге, и я подозреваю, что не могу сделать намного лучше, чем процитировать его:

Итак, да, часто звучащая критика «методы расширения не объектно-ориентированный "совершенно правильно, но также довольно не имеет значения. расширение методы конечно не объектно-ориентированный. Они ставят код который манипулирует данными далеко из кода, который объявляет данные, они не могут нарушить инкапсуляцию и поговорить с частным государством объекты, на которых они кажутся методами, они плохо играют с наследование и тд. Они процедурное программирование в удобной объектно-ориентированное платье.

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

Я бы добавил, однако, что они полезны не только для LINQ - по той же причине, что они полезны в LINQ. Очень приятно иметь возможность выражать алгоритмы, которые работают на произвольных реализациях определенного интерфейса (например, IEnumerable<T> в LINQ to Obhects). Такие алгоритмы обычно не имеют никакого контекста, кроме интерфейсов, над которыми вы работаете, поэтому они часто являются статичными.

Если вы согласны, что у вас есть какой-то статический служебный метод, какой синтаксис вы бы предпочли использовать?

// Traditional
CollectionUtils.Sort(collection);

// Extension methods
collection.Sort();

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

Answer 2

Это две части.

1. ОО, когда мы его используем Нет; это заставляет вас чувствовать, что вы вызываете метод определенного типа

2. Это ОО в зависимости от того, как он скомпилирован / собран

Да; Скомпилированный код имеет статический метод, использующий объект, для которого был вызван метод расширения

Answer 3

Методы расширения не являются объектно-ориентированной функцией языка. (по сравнению с классами, наследованием, полиморфизмом и т. д.).

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

• Каковы лучшие методы использования методов расширения в .Net?
• Возможные злоупотребления методами расширения
• Способы расширения скрывают зависимости?

Answer 4

Методы расширения - это просто статические методы, которые работают с определенным классом или иерархией классов. Python является OO, но имеет модули, а Ruby имеет миксины. Я вижу это больше как языковую особенность. Я уверен, что он все еще ОО дружелюбный

Answer 5

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

Answer 6

Методы расширения - это всего лишь языковая функция. Они работают с экземплярами объектов и являются очень хорошим инструментом.

Рассматривайте их как другой способ расширения функциональности класса. Вы можете добавить новую функциональность в класс:

• Путем добавления частичного объявления класса. Затем класс мгновенно получает кучу новых методов и свойств.

• Включая пространство имен в класс держателя методов расширения. Затем класс снова получает несколько новых методов.

Скорее организационная / языковая особенность. Никоим образом не нарушает объектно-ориентированную концепцию. Подобно тому, как разделение заголовочных / исходных файлов в C / C ++ не имеет ничего общего с объектной ориентацией, это просто функция языка / фреймворка.