Pull to refresh
17
0
Андрей Мартынов @avmartynov

User

Send message

https://cdnpdf.com/embed/8017-infrastruktura-programmnyh-proektov-soglasheniya

5.6 Методы расширения (стр. 176)

Много интересного на эту тему.

Да. Многословнее. А главное придётся явно указать тип. В Вашем варианте этого удаётся избежать.

Надеюсь, что когда-нибудь нам позволят писать просто new[0], без указания типа (как это уже сейчас можно делать в некоторых других случаях).

Для конвертации нула во что либо хорошо подходит оператор ?? (операция дефолтного значения). Очень ясно и стандартно выражает мысль: "если переменная случится нуловая, надо заменить её значение на вот такое значение". Это стандартное средство языка, любой программист поймёт такой код однозначно и без проблем.

IsNullOrEmpty(this string.. - постоянно вижу во многих проектах такой самописный метод расширения.

А вы не задумывались, почему разработчики Miсrosoft за столько лет не написали такой метод расширения - IsNullOrEmpty? или подобный... "Ума им не хватило" что ли?

Нет. Не написали, потому что это было бы неправильно. И вы не пишите.

Когда я вижу, что для переменной, которая может содержать null, безусловно вызывается какой-нибудь метод, в моей голове включается сирена. Приходится разбираться, что это за метод (настоящий или расширение), лезть в код метода расширения, чтобы убедиться, что всё будет в порядке. Только тогда сирена выключается...

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

Для обеспечения этого поведения, обычно (на самом деле всегда) this-аргумент
проверяют на null и в случае необходимости генерят ArgumentNullException.

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

Добавил раздел про ограничения на параметры и возвращаемое значение при работе сгенерированного кода в песочнице. Это существенно — можно использовать только сериализуемые типы и типы, производные от MarshalByRefObject.
otherwise, the default value for type T.

Удивлён. Поражён. Перепутал с First, который генерит исключение, если не нашёл ничего по заданному критерию, т.е. фактически выполняет поиск. Я его (First) всегда и использую для поиска…
Моё имхо:

Для решения вопроса генерить или нет исключения, применяется простое правило: если метод не выполнил действие, которое его просили выполнить, то надо генерить исключение.

Если говорят «дай!» (get), а он не даёт, то генерится исключение.
Если говорят «найди!» (find) а он не находит, то генерится исключение.

Наверное вы путаете английские слова find (найти, найди!) и search (seek, look for), (искать, ищи!)

Короче, find должен или находить, или генерить исключение,
а search (seek, look for) должен искать и сообщать о результате поиска,
который может быть отрицательным (не нашёл) или положительным (нашёл, что нашёл).

Такого принципа последнее время придерживаются и в Microsoft (см. например Find из Linq).
Название топика изменил. И в тексте… Спасибо.
Думаю, что программирование на IL это не для тех, кому некогда… Цель представленной библиотеки — сделать встраивание в программу динамического кода рутинным, простейшим делом. Главным было сэкономить время разработчика, предоставить инструмент для программирования «на скорую руку».
Ситуация: Петя вызывает метод класса, разработанного Васей, и передаёт ему как параметр экземпляр класса, разработанного Мишей.

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

К кому идти Пете, к Васе или к Мише? Кто может лучше успокоить Петю, кто обеспечит гарантии?

Ответ 1: Без Миши никак не обойтись. Если только Миша заранее не предусмотрел у своего класса ReadOnly интерфейс. Если ReadOnly интерфейс уже есть, то Вася справиться и сам. Он переделывает свой метод, так, чтобы он принимал на вход именно этот ReadOnly интерфейс. Петя теперь будет спокоен.

Ответ 2: Если Миша не предусмотрел у своего класса ReadOnly интерфейс, и не собирается это делать? То можно обойтись и без него (и без Васи кстати тоже). Передадим в Васин метод копию экземпляра Мишиного класса. Дорого? Да. Но мы в безвыходной ситуации…

Статья по-моему написана для Миши. Как ему сделать по-настоящему надёжный ReadOnly интерфейс, защищающий от downcast'а.

Ответ 3: Возможен ещё один метод успокоения Пети, упрощающий Мише реализацию ReadOnly интерфейса. Надо чтобы Вася ничего не знал от Мишином классе, а знал только об его ReadOnly интерфейсе. Тогда он не сможет (физически) сделать downcast. И Петя будет совершено спокоен. Миша может в этом случае реализовать интерфейс «по-простому». Но тогда придётся разнести ReadOnly интерфейс и реализацию класса по разным сборкам. Пете дать и реализацию и интерфейс, а Васе только интерфейс. Но возможно это уже слишком?..

Information

Rating
Does not participate
Location
Москва, Москва и Московская обл., Россия
Date of birth
Registered
Activity