Нэш Трей - C# 2010. Ускоренный курс для профессионалов (2010) (1160865), страница 130
Текст из файла (страница 130)
Это значит, что если реализуется метод, подобный 1,одтоу11е, внутри которого изменяется некоторое глобальное состояние, используемое другими компонентами приложения, то тем самым создается потенциально опасный побочный эффект. Подобные побочные эффекты обычно являются причиной многих трудно обнаруживаемых ошибок.
В данном случае модификация глобального состояния может быть не интуитивно понятной, если исходить только из имени метода. По той же причине следует стараться избегать создания побочных эффектов для клиентов, когда они импортируют пространства имен. В частности, гораздо лучше, если расширяющие методы будут объявляться в собственном пространстве имен, отдельном от пространств имен, где расположены расширяемые типы. Обычно расширяющие методы находятся во вложенном пространстве имен. Не предоставление клиентам подобной модульности может привести к путанице во время поиска компилятором метода для вызова метода экземпляра. Представьте на мгновение, какую путаницу может внести определение расширяющих методов в пространстве имен Бузсегя.
Не существует механизма, который бы удержал от этого. Пространство Бузсея импортируют в свой код практически каждый. Поэтому, если определить расширяющие методы в Бузгекь то большинство разработчиков автоматически импортируют их, и единственный способ предотвратить это — смириться с неудобством полного отказа от импорта пространства имен Бузсез! Если вы полагаете, что это не такая уж большая проблема, давайте рассмотрим следующий сценарий. Предположим, что есть приложение, использующее библиотеку Асше ЧЧ!г!яе1э. Разработчики Асгпе Ю!бяе1з думали, что будет удобно предоставить расширяющий метод по имени Нг11еЬоо, который станет еще одним инструментом отладки для их библиотеки. Будучи хорошими дизайнерами, они определили расширяющий метод в пространстве имен Асаехыдесехсепз1опз. позже вам встретилась библиотека Расширяющие методы 485 Асе ОЬ1ес1з, и вы решили ею воспользоваться.
Перед внесением изменений в код ссылка на эту сборку была включена в проект, в результате чего весь код перестал компилироваться — компилятор сообщает об ошибке С80121, гласящей, что вызовы Кг1геЬоо неоднозначны. Внимательное исследование показывает, что разработчики Асе ОЬ1естз также решили. что будет полезно предоставить расширяющий метод с тем же именем Хг1геЬоц. К сожалению, они определили его в пространстве имен Зузгев, которое импортирует весь ваш код. Вот напасть! Мораль этой истории в том, что расширяющие методы всегда нужно определять в отдельном пространстве имен, чтобы обеспечить клиентам возможность тонкой настройки при импорте их в свой контекст.
Более того, предоставляя большой набор методов расширения, рассмотрите возможность дальнейшего его разнесения по нескольким пространствам имен, чтобы обеспечить более высокую степень модульности. Изменение контракта типа может нарушить работу расширяющих методов При поиске компилятором имени, соответствующего вызову метода экземпляра, расширяющие методы просматриваются в последнюю очередь.
Это имеет смысл, поскольку если есть класс, который уже реализует метод экземпляра по имени хг1сеьод, то вряд ли нужно, чтобы расширяющий метод заменил его функциональность. Однако рассмотрим следующий сценарий. Пусть имеется приложение, использующее библиотеку Асше 1Ч!бде1з, Чтобы помочь в отладке н предоставить богатый механизм протоколирования, создан расширяющий метод по имени Иг1геЬод, который можно использовать для вывода информации о конкретном графическом элементе в файл журнала. Со временем было решено перейти ко второй версии библиотеки Асше утт!бде1з. А между тем создатели библиотеки Асше утт!т1де1э решили расширить общедоступный контракт для некоторых из ее типов и добавили метод КгагеЬод, потому что перед реализацией собственного расширяющего метода ыгат еьоо вы отправили им запрос на создание новых средств. Не зная, что они добавили этот метод в свои типы, вы перекомпилируете код.
Никаких ошибок не возникает, поскольку по случайности сигнатура новых методов экземпляра в точности совпала с сигнатурой вашего расширяющего метода. Но после запуска приложения обнаруживается, что его поведение изменилось, и формат файла журнала стал совершенно другим! Это произошло потому, что теперь компилятор отдал предпочтение методу экземпляра перед расширяющим методом. Неприятные вещи подобного рода могут произойти. если определение типа включает новое свойство с тем же именем, что и у расширяющего метода. Но в этом случае компилятор сообщает об ошибке, связанной с попыткой обращения к свойству как к методу. Единственное реальное решение описанной проблемы состоит в использовании для вызова расширяющего метода классического синтаксиса вызова статического метода, а не синтаксиса вызова расширяющего метода экземпляра.
Но если случилось нечто подобное приведенному выше сценарию, то может пройти какое-то время, прежде чем вы осознаете, что расширяющий метод должен вызываться иначе. Трансформации Несмотря на то что расширяющие методы — это просто синтаксические сокращения для вызова статических методов с использованием стандартного синтаксиса вызова методов, иногда такое кажущееся упрощение может стимулировать мыслительный процесс, открыв дорогу новым идеям. Например. предположим, что есть коллекция 486 Глава 14 данных. Пусть эта коллекция реализует интерфейс 1ЕппыетаЬ1е<Т>. Теперь необходимо применить к каждому элементу коллекции некоторую операцию и произвести новую коллекцию.
Для примера предположим, что имеется коллекция целых чисел, и ее нужно трансформировать в коллекцию чисел с плавающей точкой двойной точности, составляющих треть от исходного значения. К решению этой проблемы можно подойти так, как показано в следующем коде: пв1пч Яувгеы) пвгпс Яувсеи.со11есг1опв.зепет1с; роЬ11с с1ввв Ттапвлоттвхвар1е ( ятвсгс чотб Ивгп() ( чвт тпсщяг = пен 11яГ<1пс>() ( 1, 2, 3, 4, 5 ); чат бооь1еьбяг = пен ь1вг<бооь1е>(); // Вычислить новый список.
готевсп( чвт 1геи 1п 1пГ(1вГ ) ( бооЬ1еь1вт.лбб( (бооЬ1е) 1гет ! 3 ) у Сопво1е.ит1Гэь1пе( 1теи ); ) Сопво1е.кт1тешпе(); /! Отобразить новый список. готеасп( чвт 1теи тп бооЫеь1вГ Сопво1е.втгтеьгпе( тсеи ); ) Сопво1е.кт1теЫпе(); Приведенный код является типичным примером императивного стиля программирования и демонстрирует правильное решение задачи. К сожалению, это решение не отличается хорошей масштабируемостью и степенью повторного использования.
Например, подумайте, что будет, если к результатам первой операцию понадобится применить вторую или. возможно, сразу три операции, выстроенные цепочкой. Или же потребуется сделать большую часть кода многократно используемой. В этом примере присутствуют как минимум две фундаментальных операции. Первая — это итерация по входной коллекции и производство новой коллекпни.
Вторая операция, ортогональная первой — деление каждого элемента на 3. Неплохо было бы их разнести, тогда при правильном кодировании код трансформации мог бы повторно использоваться в самых разных операциях. Для начала отделим операцию от трансформации и посмотрим, как будет выглядеть код: ов1пд Яувтеи; свтпд Яув'еи.Со11есттопв.пепет1с) роЬ1тс с1ввв Ттвпвготиахввр1е ( бе1еоате бооЫе Оретвттоп( 1пс 1геи ); вгвгбс ььвг<бооые> ттапвтотт( швг<тпг> 1прог, Оретаг1оп ор ) ( ьавг<бось1е> теяо1г = пен Валс<босые>(); Готевсл( чвт 1Геы 1п торос ) ( тевп1Г.Лбб( ор(1Гет) ); тесотп тево1Г; ) всаттс бооЫе ГачтбеВуТЬтее( тпт и ) ( теготп (бооЬ1е)п / Зу Расширяющие методы 487 згаСЬс чо1г) Маап() чаг 1пСЬЬяг = пен Ьазг<1пг>() ( 1, 2, 3, 4, 5 ); // Вычислить новый список.
чаг боиЫеЬЬзг = Тгапятога( ЬпСЬЬзг, Р1чабеВуТЬгее ) Гогеась( чаг Ьгеи гп Ьпгьгзг ) ( Сопзо1е.игагеьтпе( 1геы )т ) Сопяо1е.игтгеЬЬпе(); // Отобразить новый список. Гогеась( чаг Егер гп бопЬ1еьаяг ) ( Сопяо1е.игггеЬЬпе( Ьгеы )т ) Сопзо1е.иг1геЬЬпе(); Новый код стал немного лучше. Операция теперь выделена и передается через делегат статическому методу Тгапя То па. Как и можно представить.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
