2010-03-03 7 views
1

Мне было интересно, какой эффективный вес методов расширения, если он используется очень дико.Эффективный вес (как во время разработки, время выполнения, так и ...) методов расширения в .NET.

Если, например, я решил создать множество методов расширения строк/int/datetime для многих повседневных задач, чтобы в результате получить какой-то свободный интерфейс, возможно, это общий вес будет накапливаться чрезмерно? И если да, будет ли это во время разработки (например, слишком много intellisense db) или времени выполнения или обоих? Или никто из них? Чтобы избежать огромного количества предлагаемых во всем мире методов intellisense, я думал о том, чтобы помещать их в отдельное пространство имен, например «MyCompany.PathExtensions» или «MyCompany.DateTimeExtensions», или даже все из них в причудливой «MyCompany.FluentEverywhere» или аналогичном ...

пример того, что я говорю о:

DateTime d; 
d = 23.Minutes().FromNow(); 
d = "14".ToIntOr(0).IsBetween(10,20).IfFalseThrow(new Exception("foo")); 

String finalPath; 
// This will give you "c:\foo\bar\" 
finalPath = "c:\\".AppendPath("foo").AppendPath("bar").EnsureTrailingBackslash(); 

String finalUrl; 
// This will give you "ftp://mycompany.com/foo/bar" 
finalPath = "mycompany".EnsureDomainExtensionOr("com").AppendPath("foo/bar").EnsureTrailingSlashNotThere().EnsureProtocolOr("ftp"); 

и так далее ... да, и не сходить с ума на такие вещи, как .IfFalseThrow(...), они были всего лишь примеры;)!

Как вы думаете? Помимо использования, что нравится или нет в зависимости от вкусов, могут возникнуть проблемы с общим весом?

Благодаря

+0

Woooh woh, не хотел запускать пламя, извините Aaronaught! Те, что я опубликовал, были просто * примерами *. Я даже написал это четко после блока кода, с смайликом тоже. Я мог бы просто сказать «banana.Eat(). Burp()', они не собирались писать новую библию. – njy

+0

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

+0

@Aaronaught - Как и во всей библиотеке Linq? :) –

ответ

2

Intellisense может измельчить дополнительные методы, но во время выполнения вы называете кучу статически определенных методов, они очень легкие.

Теперь некоторые из методов расширения Linq являются тяжелыми, но это потому, что они делают работу, а не только потому, что они являются методами расширения.

Как вы сказали, все зависит от внешнего вида/цепочки и т. Д., Но для производительности есть ничего не добавлено с помощью метода расширения для чего-то.

+0

Спасибо, Ник, на самом деле, кроме кодового времени, я подозревал, что во время выполнения было не так много, но хотелось бы быть уверенным в этом, обсуждая немного. – njy

3

что является эффективным весом методов расширения

Точно так же, как эффект использования статических метод. Методы расширений не более, не меньше, чем просто статические методы, завернутые синтаксическим синтаксисом C#, чтобы они выглядели как обычные методы.

+0

Я знаю, что они статические методы, это понятно, когда вы пишете их;) ... но они не * просто * это. Фактически, «синтаксический сахар» имеет стоимость, по крайней мере, во время проектирования/кодирования: база данных intellisense растет (может быть?) Слишком много и так далее ... я обсуждал об этом предмете – njy

+0

У него есть только затраты на компиляцию , отладка. Как каждый метод, который вы заявляете. Если вы хотите избежать «накладных расходов», то ничего не объявляйте :). Серьезно, это настолько несправедливо, что я даже никогда не хотел об этом спрашивать. Особенно, когда это не влияет на производительность в производстве. –