Должны ли расширения добавляться в С# 4.0?

Ответ 1

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

public bool IsInTransaction
{
    get { return _session.Is().Not.Null && _session.Is().InTransaction; }
}

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

Ответ 2

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

Ответ 3

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

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

Ответ 4

Я не знаю, почему нет. Свойства - это только методы getter/setter с разным синтаксисом.

Ответ 5

Я не думаю, что свойства расширения были бы почти полезны. Я в основном использую свойства для инкапсуляции полей (классический get, set;) или для обеспечения чистоты только для чтения (просто получить личное, readonly, contructor-set field). Поскольку расширения не могут получить доступ к частным членам, я действительно не вижу смысла, особенно для "set;". Чтобы сделать что-нибудь, "установить"; просто нужно было бы вызвать другие методы. Затем вы сталкиваетесь с проблемой исключения исключений свойств.
Поскольку расширения ограничены использованием общедоступных свойств и методов, я считаю, что он чище и проще читать код, который использует класс утилиты. Когда дело доходит до этого, мы используем методы расширения, чтобы LINQ выглядел красиво. Чтобы разработчики не поступали неправильно, я могу иметь дело с дополнительным() здесь и там в моем LINQ и придерживаться только методов расширения.

Ответ 6

Я предполагаю, что это было бы здорово, если в их использовании нет или минимального штрафа за производительность.

Ответ 7

Похоже, это легко можно было использовать неправильно. Как отмечали другие, свойства С# - это просто синтаксический сахар для методов. Однако реализация этих свойств в качестве свойств имеет определенные коннотации: доступ не будет иметь побочных эффектов, а изменение свойства должно быть очень недорогим. Последний момент имеет решающее значение, поскольку свойства расширения почти всегда будут дороже обычных свойств.

Ответ 8

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

Ответ 9

Определенно добавит в репертуар инструментов в нашем распоряжении.

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

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

Ответ 10

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

Ответ 11

Разработчики должны использовать свойства для организации иерархии имен и избегать конкатенации имен с помощью верблюжьей оболочки или подчеркивания. Например, вместо HttpUtility.UrlDecode они должны расширить класс строк, чтобы использовать что-то вроде "some str".decode.url В настоящее время единственный способ сделать это в С#: "some str".decode(). Url

Ответ 12

Да, пожалуйста.

А также добавьте индексированные свойства и материал расширения STATIC, потому что я СЕРЬЕЗНО хочу, что для System.Console(это не значит, что это шутка!).

Ответ 13

Нет, свойство - это просто способ скрыть то, что действительно было создано для кода. Если вы посмотрите на отраженный код или IL, вы можете определить, что вы действительно получаете, и это следующее:

public string MyProperty { get; set; }

становится

public string get_MyProperty(){ return <some generated variable>; }
public string set_MyProperty(string value) { <some generated variable> = value; }

Это всего 2 метода.