Есть ли успех для создания методов расширения, которые работают с типом объекта?

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

public static string FormatSomething(this object o)
{
     if( o != null )
     {
          string s = o.ToString();
          /// do the work and return something.
     }
     // return something else or empty string.

}

Основная причина, по которой я использую тип объекта, а не строку, - это сохранить себя в пользовательском интерфейсе из-за необходимости делать <%#Eval("Phone").ToString().FormatSomething()%>, когда я могу сделать <%#Eval("Phone").FormatSomething()%> вместо этого.

Итак, хорошо ли с точки зрения производительности создавать все методы расширения для объекта или я должен преобразовывать их в строковые (или соответствующие) типы на основе того, что делает метод расширения?

Ответы

Ответ 1

Есть ли производительность для создания методов расширения, которые работают с типом объекта?

Да. Если вы передадите тип значения, тогда будет указан тип значения. Это создает ограничение производительности при распределении поля и выполнении копии, а также, конечно, позже, чтобы мусор собирать ящик.

Вместо

public static string FormatSomething(this object o) 
{
    return (o != null) ? o.ToString() : "";
}

Я бы написал

public static string FormatSomething<T>(this T o) 
{
    return (o != null) ? o.ToString() : "";
}

Это имеет тот же эффект, но избегает штрафа за бокс. Вернее, он торгует штрафом за бонус за каждый штраф за первый штраф за джинг.

Хорошо ли с точки зрения производительности создавать все методы расширения на объекте?

Мы не можем ответить на вопрос. Попробуй! Измерьте производительность, сравните ее с желаемой производительностью и убедитесь, что вы достигли своей цели. Если да, то отлично. Если нет, используйте профайлер, найдите самую медленную вещь и исправьте ее.

Но ни один вопрос не является вопросом, который вы должны задать. Вопрос, который вы должны задать:

Хорошая практика программирования для создания метода расширения, который расширяет все?

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

Например, предположим, что вы хотите иметь метод расширения, который отвечает на вопрос "содержит ли эта последовательность это значение?" Вы можете написать:

public static bool IsContainedIn<T>(this T item, IEnumerable<T> sequence)

а затем скажите

if (myInt.IsContainedIn(myIntSequence))

Но гораздо лучше сказать:

public static bool Contains<T>(this IEnumerable<T> sequence, T item)

а затем скажите

if (myIntSequence.Contains(myInt))

Если вы делаете это первым способом, то вы печатаете в IDE, и каждый раз, когда вы вводите ".", вы получаете запрос с IsContainedIn в качестве опции, потому что, возможно, вы собираетесь написать код, который определяет если этот объект находится в коллекции. Но в 99% случаев вы этого не сделаете. Это добавляет шума к инструменту и затрудняет поиск того, что вы действительно хотите.

Ответ 2

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

Ответ 3

По сравнению с тем, когда вы вызываете ToString для вызова FormatSomething на самом деле (у вас есть нулевая проверка, может потребоваться еще несколько ms, но они также делают код более надежным.

Даже если тип времени компиляции объекта, который вы вызываете методом on, был строкой, он все равно будет иметь заметную разницу.

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