Недостатки дополнительных методов?

Question

Недостатки дополнительных методов?

Хорошей идеей является использование «объектно-реляционного картографа», подобного Idiorm :

$user = ORM::for_table('user')
->where_equal('username', 'j4mie')
->find_one();

$user->first_name = 'Jamie';
$user->save();

$tweets = ORM::for_table('tweet')
    ->select('tweet.*')
    ->join('user', array(
        'user.id', '=', 'tweet.user_id'
    ))
    ->where_equal('user.username', 'j4mie')
    ->find_many();

foreach ($tweets as $tweet) {
    echo $tweet->text;
}

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

28

extension-methods c#

задан Casebash 21 March 2010 в 10:45

5 ответов

Несколько вещей:

не всегда ясно как, туда, где дополнительный метод прибывает из того, если Вы не в VS.NET
, Дополнительные методы не могут быть разрешены через отражение или C# 4.0's динамический поиск

4

ответ дан Buu Nguyen 28 November 2019 в 03:23

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

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

я обычно делаю дополнительные методы как обертки к моим собственным классам или классам BCL, и помещаю их в пространство другого имени. например, Utils и Utils. Расширения. Тем путем extesions не должны использоваться.

3

ответ дан Lance Fisher 28 November 2019 в 03:23

сверяющиеся с пустым указателем статические методы отличается. Не обязательно лучше или хуже - но отличающийся, и разработчик должен понять это. Способность назвать метод на нулевом значении может быть неожиданной, и может (время от времени) быть очень полезной.
Никакой полиморфизм (хотя перегрузка поддерживается)
можно попасть в беду с неоднозначностью, если два дополнительных конфликта методов для исходного типа (и ни один не квалифицирует как "лучше"). Компилятор тогда отказывается использовать любого..., что означает добавлять, что дополнительный метод в блоке A может повредиться* несвязанный код в блоке B. Я видел это пару раз...
Вы не можете использовать в с C# 2.0, поэтому если Вы пишете библиотеку для C# 2.0, это не помогает
, Этому нужно [ExtensionAttribute] - поэтому, если Вы пишете библиотеку для.NET 2.0, Вы входите в рассол: если Вы объявляете Ваш собственный [ExtensionAttribute], он мог бы конфликтовать от.NET, 3,5 вызывающих стороны

не понимают меня превратно, хотя - я - большой поклонник!

можно, вероятно, предположить, что я в настоящее время пишу библиотеку, которая должна работать на C# 2.0 и.NET 2,0 вызывающих стороны - и где (раздражающе) дополнительные методы были бы действительно, действительно полезны!

* =for компилятор только; код, который уже компилируется, будет прекрасен

2

ответ дан Marc Gravell 28 November 2019 в 03:23

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

0

ответ дан 1800 INFORMATION 28 November 2019 в 03:23

Другие вопросы по тегам:

extension-methods c#

Похожие вопросы:

score 36 · Accepted Answer

способ, которым импортируются дополнительные методы (т.е. целое пространство имен за один раз) не детализирован. Вы не можете импортировать одно расширение из пространства имен, не получая все остальные.
не сразу очевидно из исходного кода, где метод определяется. Это также преимущество - это означает, что можно заставить код выглядеть согласовывающимся с остальной частью методов на типе, даже если Вы не можете положить его на то же место по любой причине. Другими словами, код более прост понять на высоком уровне, но более сложный с точки зрения точно , что выполняется. Я утверждал бы, что это верно для LINQ в целом, также.
у Вас могут только быть дополнительные методы, не свойства, индексаторы, операторы, конструкторы и т.д.
, Если Вы расширите сторонний класс, и в более поздней версии они начинают новый метод с той же подписи, Вы не будете легко знать, что значение Вашего кода вызова изменилось. Если новый метод очень подобен к Вашему расширению, но с тонко различными граничными условиями (или безотносительно) тогда это могло привести к некоторым очень хитрым ошибкам. Это относительно вряд ли произойдет все же.