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