2008-10-22 4 views
2

Я обычно использую методы расширения очень экономно. Когда я чувствую себя вынужденным написать метод расширения, я иногда хочу перегрузить метод. Мой вопрос в том, что вы думаете о методах расширения, называющих другие методы расширения? Плохая практика? Это неправильно, но я не могу определить, почему.C# Расширения

Например, второй метод CaselessIs называет первым:

public static bool CaselessIs(this string s, string compareTo) 
{ 
    return string.Compare(s, compareTo, true) == 0; 
} 

public static bool CaselessIs(this string s, IEnumerable<string> compareTo) 
{ 
    foreach(string comparison in compareTo) 
    { 
     if (s.CaselessIs(comparison)) 
     { 
      return true; 
     } 
    } 

    return false; 
} 

было бы более целесообразно не делать этого? Недостатком было бы то, что он нарушает DRY.

public static bool CaselessIs(this string s, string compareTo) 
{ 
    return string.Compare(s, compareTo, true) == 0; 
} 

public static bool CaselessIs(this string s, IEnumerable<string> compareTo) 
{ 
    foreach(string comparison in compareTo) 
    { 
     if (string.Compare(s, comparison, true) == 0) 
     { 
      return true; 
     } 
    } 

    return false; 
} 
+0

«CaselessIs» - не очень интуитивное имя функции. Я бы рекомендовал, возможно, изменить его на «CompareCaseless» – 2008-10-22 18:55:54

ответ

9

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

extended.ExtensionMethod(foo); 

к:

StaticType.ExtensionMethod(extended, foo); 

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

3

лично я не вижу проблемы с этим, второй сценарий я думаю, чувствует себя более неправильно ....

1

У меня нет проблем с этим, сам - хотя, если она заставляет вас чувствовать себя лучше, вы могли бы, конечно, использовать статическую версию вместо:

public static bool CaselessIs(this string s, IEnumerable<string> compareTo) 
{ 
    foreach(string comparison in compareTo) 
    { 
     if (Extensions.CaselessIs(s, comparison)) 
     { 
     return true; 
     } 
    } 

    return false; 
} 

Лично в этом примере, я бы назвал его CaselessMatches, и имел исключительное требование множественного числа ... но это, как ни странно, я полагаю.

2

Совершенно верно. Почему это должно быть неправильно?

Как вы определяете метод расширения, вы подразумеваете нацеленность на фреймворк 3.0 (на самом деле расширения для компилятора новых языков), поэтому нет ничего плохого в том, чтобы использовать только другое расширение для выполнения этой работы.

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

1

Я не вижу в этом ничего плохого. Предположим, вы создали someClass.ToMySpecialString(). Почему бы вам не перегрузить его, если someClass.ToString() уже имеет несколько перегрузок?

Смежные вопросы