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