Нэш Трей - C# 2010. Ускоренный курс для профессионалов (2010) (1160865), страница 39
Текст из файла (страница 39)
Однако тот факт, что язык предоставляет их, не означает, что ими нужно злоупотреблять. За последнее десятилетие многие эксперты опубликовали многочисленные книги, посвященные эффективному и безопасному проектированию приложений на С++ и бава. В этих работах чаще говорится о вещах, которых вы не должны делать, чем о вещах, которые делать нужно. Причина в том, что С++, наряду с Св, предоставляет в ваше распоряжение арсенал средств, применение которых не обязательно укладывается в рамки требований хорошего дизайна.
В конце концов, вы должны стараться создавать классы и конструкции, интуитивно понятные в применении и свободные от скрытых сюрпризов. Сообразительный читатель, возможно, отметит, что модификатор сев — кратчайший путь к появлению некоторых серьезных сюрпризов в иерархии классов. Если вы обнаруживаете, что не можете обойтись без модификатора в определении метода, то, скорее всего, это свидетельствует о том, что вы используете класс таким способом, для которого он не предназначен. Возможно, производится наследование от класса.
который должен был быть помечен как зез1ео. Вы можете ругать разработчика этого класса за то, что он не пометил определенный метод модификатором чьгг эа1, чтобы его можно было легко переопределить. И тогда вы прибегаете к модификатору сея. Только на основании его существования не следует предполагать, что его нужно широко использовать. Проектировщик класса, от которого осуществляется наследование, возможно, не намеревался разрешать выполнять наследование, а просто забыл указать зеа1еб в объявлении своего класса. И даже хотя такой проектировщик нечаянно оставил свой класс не герметизированным, он, вероятно, не собирался позволять заменять метод, который вы пытаетесь переопределить. Таким образом, всегда старайтесь применять проверенные временем приемы проектирования и избегать этих "великолепных" средств языка, которые противоречат принципам хорошего дизайна.
Наследование, включение и делегирование Когда несколько лет назад многие начали программировать на объектно-ориентированных языках, наследование считалось самым великолепным изобретением со времен бутерброда. Фактически, многие люди рассматривали его как неотъемлемую и важнейшую часть объектно-ориентированного программирования. Некоторые утверждали, что язык, не поддерживающий наследования, вообще не является объектно-ориентированным.
В споры на эту тему были вовлечены многие люди в течение многих лет, и периодически зти споры принимали форму религиозных войн. Однако с истечением времени некоторые умные проектировщики стали замечать ловушки. присущие наследованию. Выбор между интерфейсом и наследованием класса Когда вы впервые открываете для себя наследование, то поначалу склонны злоупотреблять им. Это случается легко.
И такие злоупотребления затрудняют понимание и сопровождение программных проектов, особенно на языках, подобных С++, которые Классы, структуры и объекты 145 поддерживают множественное наследование. Получающийся дизайн трудно адаптировать для будутцих потребностей, что заставляет отбрасывать его и заменять совершенно новым. В языках, поддерживающих только одиночное наследование, таких как С№ и дача, разработчик вынужден более тщательно подходить к применению наследования. Например, моделируя систему управления кадровыми ресурсами в компании ХРЕ, наивный дизайнер может завести классы вроде Рауее (получатель платежа], Веоеу№сзкесар1еог (получатель дохода) и Рече1орег (разработчик).
Затем, применив множественное наследование, он может представить составной класс наемного разработчика Ри11г тглерече1орег, унаследовав его от всех трех, как показано на рис. 4.3. Рис. 4.3. Пример неудачного наследования Как видите, это заставит нашего горе-дизайнера создать новый класс для представления разработчиков по контракту, который не наследуется от Веоег№гзкес1раелк. По мере роста системы быстро обнаруживаются недостатки в дизайне, когда структура наследования станет достаточно сложной и глубокой.
Теперь получится два класса для разных типов разработчиков, что затруднит управление таким дизайном. А теперь рассмотрим неудачную попытку решить ту же проблему на языке. поддерживающем только одиночное наследование. Как видно на рис. 4.4, это решение не лучше предыдущего. Рис. 4.4. Пример неудачной иерархии с одиночным наследованием Если внимательно присмотреться, обнаружится некоторая неоднозначность.
В среде, где разрешено только одиночное наследование. нельзя, чтобы класс Вехге1орег наследовался одновременно от Рауее и Веоеб№гзкесараепт. По этой причине не может быть двух иерархий в одном и том же дизайне. Вам придется создать два разных варианта класса Вече1орег — один для наследования от него Ро111№терече1орег, а другой — для наследования Сооггасгрече1орег.
Однако это будет пустой тратой времени. Что более важно, если требуется создавать две версии по существу одного и того же класса, то пропадает возможность многократного использования кода, а это является главным преимуществом наследования. Более удачный подход состоит в том, чтобы иметь класс Вече1орег, содержащий различные свойства, которые представляют определенные характеристики разработчиков внутри компании.
Например. поддержка специфического интерфейса может характеризоваться поддержкой определенного свойства. Иерархия наследования с большим количеством уровней в глубину — явный признак того, что дизайн нуждается в переосмыслении. 146 Глазе 4 Чтобы увидеть, что в действительности происходит здесь, давайте проанализируем, что именно означает для вас наследование. В действительности оно позволяет бесплатно сэкономить часть работы за счет наследования реализации. Есть существенное отличие между простым наследованием и наследованием реализации.
Хотя объектноориентированные языки, в том числе и С», обычно используют сходный синтаксис для этих двух видов наследования, важно отметить, что классы, реализующие интерфейс, не получают никакой готовой реализации вообще. При использовании наследования, однако, вы не только наследуете общедоступный контракт базового класса, но также наследуете компоновку, или все его внутренности. Хорошее эмпирическое правило гласит, что если целью является, прежде всего, наследование контракта, то следует выбрать реализацию интерфейса вместо наследования. Зто гарантирует дизайну базьшую гибкость.
Чтобы понять, почему это так, давайте исследуем подводные камни, присущие наследованию. Сравнение делегирования и композиции с наследованием Другой важный аспект наследования состоит в том, что оно может быть вредным: наследование может розрушшпь инкопсуля))ию и всегда усиливает связность. Наверняка все согласны с тем, что инкапсуляция — наиболее фундаментальная н важная объектно-ориентированная концепция. Если это так, то зачем разрушать ее'? Если в поддержку инкапсуляции базовый тип содержит защищеяные поля, а вы нарушаете целостность оболочки инкапсуляции и открываете внутренности базового класса, то это не может быть хорошо.
Ниже рассматриваются доступные альтернативы. которые позволяют разработать лучший дизайн. Многие описывают наследование как повторное использование типа "белого ящика". Лучшая форма повторного использования — это "черный ящик", когда внутренности объекта не открываются внешнему миру. Достичь этого можно, применив отношение включения (сопга)пшено). Да, это правильно. Вместо наследования нового класса от другого, можно включить экземпляр этого другого класса в создаваемый, тем самым повторно используя класс включенного тица без нарушения инкапсуляции. Недостаток такого приема связан с тем, что в большинстве языков, включая СЗ, это потребует чуть больше работы по кодированию, хотя и не намного. Зато в результате получится более адаптируемый дизайн.
В качестве простого примера рассмотрим предметную область, где класс обслуживает некоторого рода специальные сетевые коммуникации. Назовем этот класс ))есноггСопгпип1сасог и предположим, что он выглядит следующим образом: риЬ11с с1аээ Кесногхсопапип1сасог ) риЪ11с чо1О Бепопзса) ОасаОЪ>есс оЬ) ( // Отправить данные по сети роЬ11с ОатаОЬ)есс Кесе1чеоаса)) ) // Принять данные по сети ) ) Теперь предположим, что позже принято решение, что было бы неплохо иметь объект ЕпсгургеакесногКСоппипьсасог, в котором данные шифруются перед отправкой. Распространенный подход — унаследовать ЕпсгурсеакесногхСоппип1сзсог ог ))егног)ссопвип1сзгог.
Тогда реализация может выглядеть так; Классы, структуры и объекты 147 риЬ11с с1азз Епсгургебнегногксошпппгсагог: Вегноггсопшппгсагог ( раЫгс ачегг1бе чо1б Яепбрага( ОагаОЬ)есг оЬЯ ( // Зашифровать данные Ьазе.Яепбрага( оЬ' ) Э рпЫгс очегггбе ОагаОЬбесг Весегчерага () ( Оасааабесс аЬб = Ьазе.кесегчераса О; // Расшифровать данные гегпгп оЬ)т ) С этим вариантом связан большой недостаток. Прежде всего, хороший дизайн требует, что для модификации функциональности методов базового класса, их следует переопределять. Для правильного их переопределения они сразу должны быть объявлены как чт.ггна1.
Это потребует некоторого преллидения будущего при проектировании класса ыесног)гсопшап1сасаг и пометки методов модификатором ч).гсаа1, но поскольку будущее предсказать не удалось, методы не были помечены как ч1гспа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}
