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

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

что будет, если вы попытаетесь задействовать данный модуль бизнес-правил в другой системе?

что будет, если вы захотите включить в систему новый пользовательский интерфейс (например, интерфейс командной строки, удобный для проведения тестирования)?

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

Стрелки между подсистемами можно рассматривать как шланги с водой. Если вам захочется «выдернуть» одну из подсистем, к ней наверняка будут подключены несколько шлангов. Чем больше шлангов вам нужно будет отсоединить и подключить заново, тем сильнее вы промокнете. Архитектура системы должна быть такой, чтобы замена подсистем требовала как можно меньше возни со шлангами.

При должной предусмотрительности все эти вопросы можно решить, проделав немного дополнительной работы. Реализуйте коммуникацию между подсистемами на основе принципа «необходимого знания», и пусть оно будет действительно необходимым. Помните: проще сначала ограничить взаимодействие, а затем сделать его более свободным, чем пытаться изолировать подсистемы после написания нескольких сотен вызовов между ними. На рис. 5-5 показано, как несколько правил коммуникации могут изменить систему, изображенную на рис. 5-4.


хранения данных

Рис. 5-5 Определив несколько правил коммуникации, можно существенно упростить взаимодействие подсистем

Чтобы соединения подсистем были понятными и легкими в сопровождении, старайтесь поддерживать простоту отношений между подсистемами. Самым простым отношением является то, при котором одна подсистема вызывает методы другой. Более сложное отношение имеет место, когда одна подсистема содержит классы другой. Самое сложное отношение - наследование классов одной подсистемы от классов другой.

Придерживайтесь одного разумного правила: диаграмма системного уровня вроде той, что показана на рис. 5-5, должна быть ациклическим графом. Иначе говоря, программа не должна содержать циклических отношений, при которых класс А использует класс В, класс В использует класс С, а класс С - класс А.

При работе над крупными программами и программными комплексами проектирование на уровне подсистем просто необходимо. Если вам кажется, что ваша



программа достаточно мала, чтобы проектирование на уровне подсистем можно было пропустить, хотя бы примите это решение осознанно.

Часто используемые подсистемы

Некоторые типы подсистем снова и снова используются в разных системах. Ниже приведены те, что встречаются чаще всего.

- Подсистема бизнес-правил Бизнес-правилами называ-

щенин бизнее-яогикй путем ее законы, директивы, политики и процедуры, реализуемые выражения в форме табпйц см, в компьютерной системе. Например, в случае системы рас-rnaey IS. чета заработной платы бизнес-правилами могли бы быть ди-

рективы налогового управления, определяющие разнообразные виды налогов. Дополнительным источником правил могло бы быть соглашение с профсоюзом, регламентирующее оплату сверхурочной работы, отпуска и т. д. При создании программы для агентства по страхованию автомобилей правила могут быть основаны на соответствующих государственных законах.

Подсистема пользовательского интерфейса Изоляция компонентов пользовательского интерфейса в отдельной подсистеме позволяет изменять его, не влияя на остальную программу. Как правило, подсистема пользовательского интерфейса включает несколько подчиненных подсистем или классов, отвечающих за GUI, интерфейс командной строки, работу с меню, управление окнами, справочную систему и т. д.

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

Подсистема изоляции зависимостей от ОС Зависимости от ОС следует изолировать в подсистеме по той же причине, что и зависимости от оборудования. Если, например, вы разрабатываете программу для Microsoft Windows, зачем ограничивать себя средой Windows? Изолируйте вызовы Windows в специализированной интерфейсной подсистеме, и если вам позднее захочется перенести программу на платформу Мае OS или Linux, то придется изменить только эту подсистему. Интерфейсная подсистема может быть слишком крупной, чтобы вы могли реализовать ее самостоятельно, однако такие подсистемы уже разработаны и включены в несколько коммерческих библиотек.

Уровень 3: разделение подсистем на классы

Этот уровень проектирования предполагает определение ттотт БД хорошо классов системы. Например, подсистема доступа к БД (смотрено » книге «АдЯе Data- может быть далее разделена на классы доступа к данным и tee Tecbni<es*(Ambler, 2003). классы хранения данных, а также метаданные БД. На рис.

5-2 показано, как разделить на классы одну из подсистем уровня 2; конечно, три других подсистемы также следует разделить на классы.



Кроме того, на этом уровне следует определить детали взаимодействия каждого класса с остальными элементами системы, особенно интерфейс класса. В целом сутью проектирования на данном уровне является декомпозиция подсистем до такого уровня детальности, который позволит реализовать части подсистем в форме отдельных классов.

Разделение подсистем на классы обычно требуется во всех

проектах, на реализацию которых уйдет более нескольких pyi высокошестшных

дней. В крупных проектах необходимы и второй, и третий классов см, в главе 6.

уровни проектирования. При работе над совсем небольшим

проектом второй уровень проектирования можно пропустить.

Классы и объекты

Один из важнейших аспектов объектно-ориентированного проектирования - различие между объектами и классами. Объект - это любая конкретная динамическая сущность, имеющая конкретные значения и атрибуты и существующая в период выполнения программы. Класс - это статическая сущность, с которой вы имеете дело, просматривая листинг программы. Например, вы можете объявить класс Person (человек), имеющий такие атрибуты, как фамилия, возраст, пол и т. д. В период выполнения вы будете работать с объектами nancy, hank, diane, tony и т. д. - иначе говоря, со специфическими экземплярами класса. Если вы знакомы с терминологией БД, различие между классом и объектом аналогично различию между «схемой» и «экземпляром». Класс можно рассматривать как форму для выпечки булочек, а объекты - как сами булочки. В этой книге термины «класс» и «объект» используются неформально и более или менее взаимозаменяемо.

Уровень 4: разделение классов на методы

Данный уровень проектирования заключается в разделении каждого класса на методы. Некоторые методы уже будут определены на уровне 3, при проектировании интерфейсов классов. На уровне 4 вы детально определите закрытые методы классов. При этом многие методы окажутся простыми, тогда как другие будут включать иерархии методов и потребуют дополнительного проектирования.

Полное определение методов класса часто позволяет лучше понять его интерфейс, что может подтолкнуть к соответствующему изменению интерфейса, т. е. к возвращению на уровень 3.

Четвертый уровень декомпозиции и проектирования часто оставляется отдельным программистам и необходим в любом проекте, требующем более нескольких часов. Формально выполнять этот этап не обязательно, но хотя бы про себя выполнить его нужно.

Уровень 5: проектирование методов

На этом уровне проектирование заключается в детальном

определении функциональности отдельных методов, за что высококачественных мето-обычно отвечают отдельные программисты, работающие над дов главы 7 м 8, конкретными методами. Данный уровень может включать

такие действия, как написание псевдокода, поиск алгоритмов в книгах, размышление над оптимальной организацией фрагментов метода и написание кода. Этот



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.0027