Книги
чёрным по белому
Главное меню
Главная О нас Добавить материал Поиск по сайту Карта книг Карта сайта
Книги
Археология Архитектура Бизнес Биология Ветеринария Военная промышленность География Геология Гороскоп Дизайн Журналы Инженерия Информационные ресурсы Искусство История Компьютерная литература Криптология Кулинария Культура Лингвистика Математика Медицина Менеджмент Металлургия Минералогия Музыка Научная литература Нумизматика Образование Охота Педагогика Политика Промышленные производства Психология Путеводители Религия Рыбалка Садоводство Саморазвитие Семиотика Социология Спорт Столярное дело Строительство Техника Туризм Фантастика Физика Футурология Химия Художественная литература Экология Экономика Электроника Энергетика Этика Юриспруденция
Новые книги
Цуканов Б.И. "Время в психике человека" (Медицина)

Суворов С. "Танк Т-64. Первенец танков 2-го поколения " (Военная промышленность)

Нестеров В.А. "Основы проэктирования ракет класса воздух- воздух и авиационных катапульных установок для них" (Военная промышленность)

Фогль Б. "101 вопрос, который задала бы ваша кошка своему ветеринару если бы умела говорить" (Ветеринария)

Яблоков Н.П. "Криминалистика" (Юриспруденция)
Реклама

Совершенный код. Мастер-класс - Макконнелл С.

Макконнелл С. Совершенный код. Мастер-класс — М.: Русская редакция, 2005. — 896 c.
ISBN: 5-469-00822-3
Скачать (прямая ссылка): soversheniykodmasterklass2005.djvu
Предыдущая << 1 .. 22 23 24 25 26 27 < 28 > 29 30 31 32 33 34 .. 426 >> Следующая

которого соответствует их навыкам и выполняемой работе. Она
позволяет разделить работу на части, над которыми отдельные
разработчики и группы могут трудиться независимо.
Хорошая архитектура облегчает конструирование. Плохая
архитектура делает его почти невозможным. Другую проблему,
связанную с плохой архитектурой, иллюстрирует рис. 3-7.
42 ЧАСТЬ I Основы разработки ПО

Рис. 3-7. Не имея хорошей архитектуры,, вы можете решать
правильную проблему, но прийти к неправильному решению.
Успешное конструирование может оказаться невозможным
Внесение изменений в архитектуру при конструировании и на
последу- Jff[L ЮЩИХ этапах обходится недешево. Время,
необходимое для исправления ошибки в архитектуре ПО,
сопоставимо со временем, нужным для исправления ошибки в
требованиях, т. е. превышает временные затраты на исправление
ошибки в коде (Basili and Perricone, 1984; Willis, 1998).
Изменения архитектуры похожи на изменения требований еще и
тем, что кажущиеся небольшими изменения могут иметь далеко
идущие последствия Чем бы ни были обусловлены изменения
архитектуры - исправлением ошибок или внесением улучшений, -
чем раньше вы осознаете их необходимость, тем лучше.
Типичные компоненты архитектуры
Удачные архитектуры имеют много общего. Если всю систе-
Перекрестная ссылка 0 низко-
уровневом проектировании про- МУ вы создаете самостоятельно,
работа над архитектурой
граммы т. главы 5-9. будет перекрываться с более детальным
проектированием
В этом случае вам следует по крайней мере обдумать каждый
компонент архитектуры. Если вы работаете над системой,
архитектура которой была разработана кем-то другим, вы должны
уметь определять ее важные компоненты без охотничьей собаки и
увеличительного стекла Как бы то ни было, далее приведен
список компонентов архитектуры, на которые следует обратить
внимание.
Организация программы
Если вы не можете объяснить В пеРвУю очеРеЛь архитектура должна
включать общее опи-
что-то шестилетнему ребенку, сание системы. Без такого
описания вам будет трудно сознан ит, вы сами этого не тт-
ставить согласованную картину из тысячи деталей
или хотя
маете бы десятка отдельных классов. Если бы система
была моза-
Альберг Эйнштейн икой из 12 фрагментов, ее мог бы с
легкостью собрать и го
довалый ребенок Головоломку из 12 подсистем собрать труднее,
но, если вы не сможете сделать этого, вы не поймете, какой
вклад вносит в систему разрабатываемый вами класс
Архитектура должна включать подтверждения того, что при ее
разработке были рассмотрены альтернативные варианты, и
обосновывать выбор окончательной организации системы. Никому
не хочется разрабатывать класс, если его роль в системе не
кажется хорошо обдуманной. Описывая альтернативные варианты,
ГЛАВА 3 Семь раз отмерь, один раз отрежь: предварительные
условия
43
Перекрестная ссылка Об используемых при проектировании
компонентах разных уровней ом. подраздел "Уровни про-
ектирования" раздела 5.2.
архитектура обосновывает организацию системы и показывает, что
роль каждого класса была тщательно рассмотрена. В одном обзоре
методик проектирования было обнаружено, что обоснование
проекта программы не менее важно для ее сопровождения, чем сам
проект (Rombach, 1990).
Архитектура должна определять основные компоненты программы. В
зависимости от размера программы ее компонентами могут быть
отдельные классы или подсистемы, состоящие из нескольких
классов. Каждый компонент является классом или набором
классов/методов, которые в совокупности реализуют
высокоуровневые функции программы, такие как взаимодействие с
пользователем, отображение Web-страниц, интерпретация команд,
инкапсуляция бизнес-правил или доступ к данным. За каждую
функцию приложения, указанную в требованиях, должен отвечать
хотя бы один компонент. Если функцию реализуют несколько
компонентов, они должны сотрудничать, а не конфликтовать.
Архитектура должна четко определять ответственность каждого
компонента. Компонент должен иметь одну область
ответственности и как можно меньше знать об областях
ответственности других компонентов. Сведя к минимуму объем
сведений, известных компонентам о других компонентах, вы
сможете локализовать информацию о проекте приложения в
отдельных компонентах.
Архитектура должна ясно определять правила коммуникации для
каждого компонента. Она должна описывать, какие другие
компоненты данный компонент может использовать
непосредственно, какие косвенно, а какие вообще не должен
использовать.
Перекрестная ссылка Минимизация объема сведений, известных
компонентам друг о друге, - главный аспект сокрытия
информации. Подробности см. в подразделе "Скрывайте секреты {к
вопросу о сокрытии информации}" раздела 5.3.
Основные классы
Архитектура должна определять основные классы приложе-
/ г г г Перекрестная ссылка 0
проек-
ния, их области ответственности и механизмы взаимодеи- тиршний
классов см гшу 8.
ствия с другими классами. Она должна описывать иерархии
Предыдущая << 1 .. 22 23 24 25 26 27 < 28 > 29 30 31 32 33 34 .. 426 >> Следующая