Главная - Литература

0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



\-I-1

Рис. 5-7 Абстракция позволяет представить сложную концепцию в более простой форме

Перекрестная ссылка 06 абстракции в контексте проектирования классое см подраздел «Хо* рошая абстракция» раздела 6.2.

Разработчики ПО иногда создают системы на уровне волокон древесины и молекул лака и стали, из-за чего такие системы становятся слишком сложными и плохо поддаются осмыслению. Если программисты не создают более общие абстракции, разработка системы может завершиться неудачей.

Благоразумные программисты создают абстракции на уровне интерфейсов методов, интерфейсов классов и интерфейсов пакетов (иначе говоря, на уровне дверной ручки, уровне двери и на уровне дома), что способствует более быстрому и безопасному программированию.

Инкапсулируйте детали реализации

Когда абстракция нас покидает, на помощь приходит инкапсуляция. Абстракция говорит: «Вы можете рассмотреть объект с общей точки зрения» Инкапсуляция добавляет: «Более того, вы не можете рассмотреть объект с иной точки зрения».

Продолжим нашу аналогию: инкапсуляция позволяет вам смотреть на дом, но не дает подойти достаточно близко, чтобы узнать, из чего сделана дверь Инкапсуляция позволяет вам знать о существовании двери, о том, открыта она или заперта, но при этом вы не можете узнать, из чего она сделана (из дерева, стекловолокна, стали или другого материала), и уж никак не сможете рассмотреть отдельные волокна древесины.

Инкапсуляция помогает управлять сложностью, блокируя доступ к ней (рис. 5-8). В подразделе «Хорошая инкапсуляция» раздела 6.2 инкапсуляция рассматривается подробнее в контексте проектирования классов.



Рис. 5-8. Инкапсуляция не только представляет сложную концепцию

в более простой форме, но и не позволяет взглянуть на какие бы то ни было

детали сложной концепции. Что видите, то и получите - и не более того!



Используйте наследование, если оно упрощает проектирование

При проектировании ПО часто выясняется, что одни объекты аналогичны другим за исключением нескольких различий. Так, при создании системы расчета зарплаты нужно учесть, что одни сотрудники работают полный день, а другие - неполный. В этом случае наборы данных, ассоциированные с сотрудниками обеих категорий, будут различаться лишь несколькими аспектами. Объектно-ориентированный подход позволяет создать общий тип «сотрудник» и определить сотрудников, работающих полный день, как сотрудников общего типа за исключением нескольких различий. Если операция над объектом «сотрудник» не зависит от его категории, она выполняется так, как если бы объект был сотрудником общего типа. Если же операция зависит от типа сотрудника, она выполняется разными способами.

Определение сходств и различий между такими объектами называется «наследованием», потому что отдельные типы сотрудников, работающих полный и неполный день, наследуют свойства общего типа «сотрудник».

Польза наследования в том, что оно дополняет идею абстракции. Абстракция позволяет представить объекты с разным уровнем детальности. Если помните, на одном уровне мы рассматривали дверь как набор определенных типов молекул, на втором - как набор волокон древесины, а на третьем - как что-то, что защищает нас от воров. Древесина имеет определенные свойства - скажем, вы можете распилить ее пилой или склеить столярным клеем, - при этом и плинтусы, и подоконники имеют общие свойства древесины, но вместе с тем и некоторые специфические свойства.

Наследование упрощает программирование, позволяя создать универсальные методы для выполнения всего, что основано на общих свойствах дверей, и затем написать специфические методы для выполнения специфических операций над конкретными типами дверей. Некоторые операции, такие как OpenQ или CloseQ, будут универсальными для всех дверей: внутренних, входных, стеклянных, стальных - каких угодно. Поддержка языком операций вроде OpenQ или CloseQ при отсутствии информации о конкретном типе двери вплоть до периода выполнения называется полиморфизмом. Объектно-ориентированные языки, такие как С++, Java и более поздние версии Microsoft Visual Basic, поддерживают и наследование, и полиморфизм.

Наследование - одно из самых мощных средств объектно-ориентированного программирования. При правильном применении оно может принести большую пользу, однако в обратном случае и ущерб будет немалым. Подробнее см. подраздел «Наследование (отношение «является»)» раздела 6.3.



Скрывайте секреты (к вопросу о сокрытии информации)

Сокрытие информации - один из основных принципов и структурного, и объектно-ориентированного проектирования. В первом случае сокрытие информации лежит в основе идеи «черных ящиков». Во втором оно дает начало концепциям инкапсуляции и модульности и связано с концепцией абстракции. Сокрытие информации - одна из самых конструктивных идей в мире разработки ПО, и сейчас мы рассмотрихм ее подробнее.

Впервые сокрытие информации было представлено на суд общественности в 1972 г Дэвидом Парнасом (David Parnas) в статье «Оп the Criteria to Be Used in Decomposing Systems Into Modules (O критериях, используемых при декомпозиции систем на модули)». С сокрытием информации тесно связана идея «секретов» - аспектов проектирования и реализации, которые разработчик ПО решает скрыть в каком-то месте от остальной части программы.

В юбилейном 20-летнем издании книги «Мифический человеко-месяц» Фред Брукс пришел к выводу, что критика сокрытия информации была одной из ошибок, допущенных им в первом издании книги. «Парнас был прав в отношении сокрытия информации, а я ошибался», - признал он (Brooks, 1995). Барри Бом сообщил, что сокрытие информации - мощный метод избавления от повторной работы, и указал, что оно особенно эффективно в инкрементных средах с высоким уровнем изменений (Boehm, 1987).

В контексте Главного Технического Императива Разработки ПО сокрытие информации оказывается особенно мощным эвристическим принципом, так как все его аспекты и даже само название подчеркивают сокрытие сложности.

Секреты и право на личную жизнь

При сокрытии информации каждый класс (пакет, метод) характеризуется аспектами проектирования или конструирования, которые он скрывает от остальных классов. Секретом может быть источник вероятных изменений, формат файла, реализация типа данных или область, изоляция которой требуется для сведения к минимуму вреда от возможных ошибок. Класс должен скрывать эту информацию и защищать свое право на «личную жизнь». Небольшие изменения системы могут влиять на несколько методов класса, но не должны распространяться за его интерфейс.

Один из важнейших аспектов проектирования класса -

Интейфейсы классов должны

принятие решения о том, какие свойства сделать доступными полными и минималь-

вне класса, а какие оставить секретными. Класс может вклю- ными.

чать 25 методов, предоставляя доступ только к пяти из них qqjj Шйв(ю

и используя остальные 20 внутренне. Класс может исполь- (Scott Meyors)

зовать несколько типов данных, не раскрывая сведений о

них. Этот аспект проектирования классов называют «видимостью», так как он определяет, какие свойства класса «видимы» или «доступны» извне.

Интерфейс класса должен сообщать как можно меньше о внутренней работе класса. В этом смысле класс во многом похож на айсберг, большая часть которого скрыта под водой (рис. 5-9).



0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 [28] 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294



0.0026