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