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

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

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

Резюме эвристических принципов проектирования

Ниже приведен список основных эвристических принци-

Больше беспокоит то, что про-

нов проектирования: грамшст вполне может выпоя

определите объекты реального мира; нить ту же задачу двумя или

определите согласованные абстракции; Р® способами: иногда нео-

сознанно, но довольно часто

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

используйте наследование, когда это возможно; создания элегантной вариации.

скрывайте секреты (помните про сокрытие информации); А, Р, Враун и У. А. Сштон

определите области вероятных изменений; *

W.A, Sampson)

Ш поддерживайте сопряжение слабым;

старайтесь использовать популярные шаблоны проектирования.

Следующие эвристические принципы также иногда бывают полезны:

стремитесь к максимальной связности;

формируйте иерархии;

формализуйте контракты классов;

грамотно назначайте сферы ответственности;

проектируйте систему для тестирования;

избегайте неудач;

тщательно выбирайте время связывания;

создайте центральные точки управления;

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

рисуйте диаграммы;

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

Советы по использованию эвристических принципов

Подходы к проектированию ПО могут быть основаны на

подходах, применяемых в других областях. Одной из первых Шр: сс2е,еот/0$92

книг, посвященных использованию эвристики при решении

проблем, является «How to Solve It (Как решать задачу)» Д. Полья (Polya, 1957). Обобщенный подход Полья к решению проблем концентрируется на решении математических задач. Он резюмирован на рис. 5-10 (шрифт оригинала сохранен).



1 Ятшиште тштш щ»т Нужно ясно тнт щту*

Что н$т&0стт? Чтдшо9В тм сосгттушв14в? Возможно т удошетворить усповш? JOaroHHo ли ушовие дпя определения нензевотного? Или недоотаточно?

Сделайте **ертеж. Введите подходящие обоаншния. Разделите условие на части. Постарайтесь записать их.

2. Сост1№Ш1И0 мтш рттш Нужно найти связь между данными и неизвестными. Если не удается сразу обнаружить эту связь, возможно, полезно будет рассмотреть вспомогательные задачи. В конечном счете необходимо прийти к /шалу решения.

Не встречалась ли вам раньше ета задача? Хотя бы в несколько иной форме? Извета ли вш тшибудь родстввиш $адта? Не знаете м теоремы, которая могла бы оказаться полезной?

Ршмотрт тт&0стмо$1 И пос1арайтесь вспомнить знакомук зщчу с тем же или подобным неизвестным. 8ог$тт, радтвншйдашойиутФршшатай. Нельзя ли воспользоваться еш? Нельзя ли применить ее результат? Нельзя ли использовать метод ее ртмт7 Не штг т ввести какой-нибуфь вспомогательный злемент. чтобы стало возможно воспользоваться прежней задшй?

Нельзя ли иначе сформулировать задачу? Еще иначе? Вернитесь к определениям.

Если не удается р%тть данную задачу, попытайтесь сигнала решить осодную. Нельзя ли придумать более доступную (жодную задачу? Более общ? более частно? Аналогичную задачу? Нельзя ли решить часть задами? Сохраните только часть условия, отбросив остальную часть; насколько определенным окажется тогда неизвестное, как оно сможет меняться? Нельзя ли извлечь 4it)-T0 полезное из данных? Нельзя ли придумать другие данные, из которых можно было бы определить неизвестное? Нельзя ли изменить неизвестное» или данные, или» вели необходимо, и то и другое так, чтобы новое неизвестное и новые данные оказались ближе др к другу?

Все ли данные вами использованы? Все ли условия? Приняты ли вами во внимание все (щесгвующие понятия, содержшеся в задаче?

а Ос)тлш1ие тша Нуто осущвтт план решения.

Осуществляя план решения, тнглютлруШ ттлй той шаг. Ясно ли вам, что предпринятый вами шаг правилен? Сумеете ли доказать, что он правилен?

4 Взглед назад. Нужно иаучиш найденное решение. Нельзя ли проварить результате Нельзя ли проверить ход решения? Нельзя т получить тот же результат инш? Нельзя ли усмотреть его с одного взгляда? Нельзя ли в какой-нибудь другой задаче использовать трр/нвтыЛ результат или метод решения?

Рис, 5-10. Д. Полья разработал подход к решению математических задач, который полезен и при решении проблем, связанных с проектированием ПО (Polyа 1957)

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



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

Никто не заставляет вас разработать весь проект за раз. Если натолкнетесь на препятствие, подумайте, обладаете ли вы информацией, достаточной для решения всех специфических проблем? Зачем через силу разрабатывать оставшиеся 20% проекта, если впоследствии они прекрасно станут на свое место? Зачем принимать неудачные решения, основанные на недостаточной информации, если позже можно будет принять более подходящие решения? Некоторые разработчики чувствуют дискомфорт, если не могут создать полный проект программы к окончанию этапа проектирования, но после создания нескольких удачных программ без заблаговременного решения всех вопросов на этапе проектирования такая ситуация начинает казаться вполне естественной (Zahniser, 1992; Beck, 2000).

5.4. Методики проектирования

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

Используйте итерацию

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

Проектирование - итеративный процесс. Выйдя из точки А и достигнув точки Б, не останавливайтесь, а вернитесь в точку А.

Изучая возможные варианты проектирования и пробуя разные подходы, вы будете рассматривать и высокоуровневые, и низкоуровневые аспекты. Общая картина, которую вы получаете при работе над высокоуровневыми вопросами, поможет вам лучше понять низкоуровневые детали. Детали, которые вы узнаете при работе над низкоуровневыми вопросами, помогут вам создать прочный фундамент для принятия высокоуровневых решений. Некоторые конфликты между высокоуровневыми и низкоуровневыми соображениями - вполне здоровое явление; это напряжение способствует созданию структуры, более стабильной, чем структура, полностью созданная «сверху вниз» или «снизу вверх».

Многим программистам - и вообще многим людям - трудно переключаться между высокоуровневыми и низкоуровневыми точками зрения, но эта способность - важное условие эффективного проектирования. Занимательные упражнения, позволяющие развить гибкость ума, можно найти в книге «Conceptual Blockbusting* (Adams, 2001), описанной в разделе «Дополнительные ресурсы» в конце главы,.

5-403



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