2009-04-21 4 views
9

Почему это? Я бы нашел это действительно приятно иметь некоторые методы расширения, заблокированные для использования только в одном из моих классов. Не действительно хотите иметь определенные методы расширения, доступные везде ... и они выглядят намного лучше, чем обычные статические методы: PМетоды расширения не допускаются во вложенных статических классах?


Для уточнения:

Поэтому я хочу, чтобы эти методы расширения происходит потому, что Я расширяю форму, на которой есть DataGridView. И я получаю очень устал от линий, как это:

foreach(var row in grid.Rows.OfType<DataGridViewRow>().Where(r => (bool) r.Cells[checkBoxColumn.Index].Value)) 

foreach(var row in grid.SelectedRows.OfType<DataGridViewRow>().Where(r => (bool) r.Cells[checkBoxColumn.Index].Value)) 

Хотел метод расширения, так что я мог бы просто сделать

foreach(var row in grid.Rows.CheckedRows()) 

foreach(var row in grid.SelectedRows.CheckedRows()) 

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

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

+0

Похоже, что ни один из этих ответов не дает хорошей технической причины, почему это невозможно. –

+0

Как и вы, я предпочитаю синтаксис метода расширения. SomeThing.HasSomeCondition() превосходит HasSomeCondition (SomeThing). – Mir

ответ

1

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

// extension method 
foreach (var row in grid.Rows.CheckedRows()) 
foreach (var row in grid.SelectedRows.CheckedRows()) 

// standard helper method 
foreach (var row in CheckedRows(grid.Rows)) 
foreach (var row in CheckedRows(grid.SelectedRows)) 
+1

возможно нет. Мне просто нравится, когда дело не в обратном направлении. вид. Хотя, может быть, мне просто нужно настроить свое мышление на «сетка -> строки -> проверенные» на «проверенные сетки -> строки» ... хм ... но я думаю, что этот вид превращается в субъективный кодировка стиль вид вещь сейчас. Хороший момент, хотя! =) Принят это как ответ, если кто-то не придет с некоторой Microsoft, связанной с «мыслью за этим». – Svish

+2

@Svish (путь позже): это не (чисто) субъективно: система без удлинения составлена ​​плохо, так как вызывает чрезмерную вложенность (то есть плохо читаемость). синтаксис расширения - это форма считывания-tailcalls, если вы будете :-) –

2

Если вы расширяете тип, то методы расширения должны быть равными доступным как и сам тип.

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

+5

Включение всех методов расширения в одном месте - это плохая идея, как использование всех методов утилиты в одном месте. –

+0

Если вы расширяете тип, ни на какой стадии, методы расширения не должны быть такими же доступными, как тип? –

+3

Я с ОП. Было бы неплохо ограничить объем ваших методов расширения. Иногда то, что вам нужно делать с типом, применяется только в определенном сценарии, но вы все же хотите использовать синтаксический сахар методов расширения. – xr280xr

4

Если у вас есть исходный код этого типа, почему вы используете методы расширения? Почему бы вам просто не сделать эти методы расширения самими типами?

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

+0

Ум, уверен, что он не создал DataGridView ;-) –

+2

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