Extension methods: stop the madness!

«каждая строка кода была произведением искусства, достойным безграничного восхищения»
Почему-то вспомнилось, что «в каждой программе есть ошибка, тогда если программа состоит из 1ой строки — в ней точно есть ошибка». Применительно к цитате из статьи: каждая строка кода была произведением искусства, достойным безграничного восхищения, но содержала ошибку… :-)

Программисты и сейчас бородатые!

Как-то Вы драматизируете.
Обычно (ну, в моём «обычно») расширения используются, когда объект нужно дополнить чем-то для него логичным, но по каким-то причинам отсутствующим. Удобнее сделать расширение, чем дочерний класс.
Допустим, я скачал Вашу сборку с кошками в виде dll. В моей программе нужно, чтобы кошка мурлыкала. Ваша кошка этому не обучена, я мог бы сделать класс MyCat, дополнив его всего одним методом, а мог бы объявить расширение. Вроде бы ничего страшного же?

Я не очень понял Вас. Вы против extension methods или их неправильного (неуместного) использования?

Не надо забывать что функции расширения — есть свертка паттерна «функция расширения» (Фаулер «Рефакторинг») — вариант реализации простой стратегии. Это синтаксический сахар и ничего более. Обе описанные вами проблемы есть и у любой стратегий.

По связке инкапсуляция-функция расширения вообще не согласен. Функции расширения позволяют лучше оттачивать интерфейсы, оставляя в них только то что действительно необходимо. Вспомните IEnumerator(IEnumerable) — я считаю его лучшем интерфейсом в .NET. А таким самодостаточным, легким и удобным он стал только с версией 3.5. До того он был довольно ущербным.

Такие мелочи, как

int32 c = str.ToInt32();

вместо

Convert.ToInt32(str);

упрощают кодинг. Мелочь, а приятно

Мне это напомнило мою недванюю дискуссию с Java программистом =) Выглядела она примерно так:
— В Яве нет свойств.
— Они нафиг не нужны — NetBeans (прим. или Eclipse, уже не помню) сам умеет создавать методы-аксессоры.
— В Яве нет делегатов.
— Всё, что в шарпе решается делегатами, без проблем решается наследованием.
— Но ведь так удобней.
— Но так меньше путаницы.

В общем, резюме — как и всё, что есть в шарпе, расширяющие методы очень удобны, но в то же время, зачастую все вопросы, которые вы хотите ими решить, можно решить банальным наследованием.

Приведу пример, когда простой расширяющий метод значительно упрощает код и делает его более читабельным (на мой взгляд), но при этом наследованием такого не сделать:

Copy Source | Copy HTML

1. public static class Extensions
2. {
3.     public static bool IsNullOrEmpty(this string str)
4.     {
5.         return string.IsNullOrEmpty(str);
6.     }
7. }
8.  
9. class Program
10. {
11.     public static void Main()
12.     {
13.         string userName = GetSomeValueFromDB("UsersTable", "UserName");
14.         if (userName.IsNullOrEmpty())
15.         {
16.             Console.WriteLine("User name is empty");
17.         }
18.     }
19. }

>>Это был поистине переломный момент, после которого, как грибы после дождя, стали появляться новые концепции и методики программирования.

Вообще-то они начали появляться как способ борьбы со сложностью программ. Это так, к слову. Но к чему это вступление о золотых временах и какая связь с Extension?

>>В то время, как при использовании статического класса у нас есть хорошо сформированное имя

Я даже знаю каким оно будет. Что-то типа ProjectName.Helpers.Converters.DogConverter.ToCat()

>>Чтобы подключить нужный метод, нам нужно прописать namespace, имя которого может оказаться совсем неочевидным.

А имя этого статического класса мы впитали с молоком матери, что-ли? То-же самое, вид в профиль.

> Непонятно, где находятся различные методы расширения, предназначенные для одного и того же класса. Непонятно, как их подключать.

Из-за таких проблем мы договорились, что все extension-методы для одного типа реализовываются в одном статическом классе вида <TypeName>Extensions. А чтобы не думать, как подключать, эти классы находятся в глобальном пространстве имён проекта. Не думаю, что это сильное «загрязнение» этого пространства имён.

В принципе, любая техника проектирования будет отстойной, если взять ситуацию, где ее применять не следует. Зачем выдумывать свой пример, если есть существующие, например, тот же Linq. Как бы вы его перепели статическими методами и во что бы превратились цепочки вызовов list.Where(…).Where(…).Take(…).Sort(…)…? И почему их отрыв от коллекции является обоснованным?

Нарушается один из основополагающих принципов ООП — инкапсуляция.

Инкапсуляция никак не регламентирует местоположение функционала.

Непонятно, где находятся различные методы расширения, предназначенные для одного и того же класса. Непонятно, как их подключать.

Если у вас нет соответствующего стандарта, то да, это проблема. У нас, например, расширение IsDbNull для Object находится в файле +System\Data\ObjectExtensions.cs и пространстве имен System.Data. Очень удобно и прозрачно. Хочу расширения объекта, связанные с СУБД, подключаю System.Data.

можно придумать ещё тысячу доводов

Сделайте одолжение.

эта вы, наверно, ещё про dynamic не слышали. вот там то можно такой ужас накуролесить…

но extension-метода даны вам для того чтобы использовать их только там где они уместны.

ваш пример с котопсом неудачен. даже самое название метода DogToCat, который будет вызываться как dog.DogToCat, уже нелепо смотрится.

но попробуйте без них обойтись в linq и asp.net mvc… тёмные времена наступят… тёмные.

У extensions methods есть еще один плюс — они поддерживаются решарпером как обычные методы.
Представьте себе, что открыли какой-то код, и хотите слегка дописать его, как раз-таки введением хелпера либо же сделав метод расширения для нужного класса. Есть ненулевая вероятность, что такой хелпер либо метод расширения для этого класса уже был кем-то написан. В таком случае, поставив после имени переменной точку и нажав Ctrl+Alt+Space — вы получите список доступных экстеншн методов из зареференсеных сборок, и сможете поискать среди них нужный, а хелпер же нужно будет искать брождением по неймспейсам в object browser-е, ну либо же смотря список usages для этого класса, что не совсем подходит для этого.

Pointless articles: stop the madness!