Отказ от перегрузок в пользу методов расширения

Question

Теперь, когда у нас есть методы расширения в C #, есть ли смысл сохранять перегрузки в реализации любого класса для передачи значений по умолчанию? Зачем загрязнять реализацию класса, когда перегрузки могут быть сделаны методами расширения? Преимущество перегрузок (для передачи значений по умолчанию)?

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

Answer 1

Теперь, когда у нас есть методы расширения в C #, есть ли смысл сохранять перегрузки в реализации любого класса для передачи значений по умолчанию?

Я бы использовал необязательные аргументы вместо методов расширения для устранения перегрузок.

Методы расширения имеют ряд недостатков - у них меньше доступа к закрытым членам, у них есть проблема с возможностью обнаружения (как они определены в отдельном классе) и т. Д.

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

• Работа с языками, которые не понимают необязательные аргументы.C # и VB.Net - не единственные языки .NET.
• Иногда необязательные аргументы просто не обрезают его - например, вам часто нужен истинный конструктор по умолчанию и необязательные аргументы, в то время как они выглядят какэто, когда вы пишете код, ведите себя по-разному в условиях отражения / сериализации / и т. д.

Answer 2

Вопрос должен заключаться не в том, «есть ли преимущества для перегрузок», а скорее в том, «каковы преимущества методов расширения, которые делают их превосходящими перегрузки?» На мой взгляд, недостатки методов расширения намного перевешивают любые предполагаемые преимущества. На самом деле, я не могу представить какое-либо преимущество, которое предоставляют методы расширения при разработке класса.

Предположим, например, что у вашего класса есть этот метод:

public int Frob(int count)

Но наиболее распространенный ожидаемый вариант использования - это когда клиенты вызывают его со значением count, равным 1. Итак, вы хотите создать метод Frob(), который не требует этого параметра.

Конечно, в .NET 4.0 вы можете сделать это с параметрами по умолчанию, но, как вы говорите, параметры по умолчанию не всегда являются опцией, потому что они должны стоять последними. Таким образом, без параметров по умолчанию у вас есть возможность 1) создать перегрузку; или 2) создание метода расширения.

Создать перегрузку просто. Создание метода расширения требует статического класса и статического метода и предоставляет возможность непреднамеренного сокрытия - все сложности, которые не приносят пользы. Зачем использовать методы расширения для эмуляции перегрузок, если вы можете просто написать перегрузку dang и покончить с этим?

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

Answer 3

В дополнение к ответу Рида Копси : методы расширения по определению являются статическими, и статика часто считается злой с точки зрения юнит-тестирования и насмешек.Вот почему я лично стараюсь по возможности избегать методов расширения.