11.5 Свод правил

В этой главе мы затронули много тем, но как правило не давали

настоятельных и конкретных рекомендаций по проектированию. Это

соответствует моему убеждению, что нет "единственно верного решения".

Принципы и приемы следует применять тем способом, который лучше

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

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

может использовать в качестве ориентиров, пока не наберется достаточно

опыта, чтобы выработать лучшие. Ниже приведен свод таких правил.

Эти правила можно использовать в качестве отправной точки в

процессе выработки основных направлений для проекта или организации

или в качестве проверочного списка. Подчеркну еще раз, что они не

являются универсальными правилами и не могут заменить размышления.

- Узнайте, что вам предстоит создать.

- Ставьте определенные и осязаемые цели.

- Не пытайтесь с помощью технических приемов решить социальные

проблемы.

- Рассчитывайте на большой срок

- в проектировании, и

- управлении людьми.

- Используйте существующие системы в качестве моделей, источника

вдохновения и отправной точки.

- Проектируйте в расчете на изменения:

- гибкость,

- расширяемость,

- переносимость, и

- повторное использование.

- Документируйте, предлагайте и поддерживайте повторно используемые

компоненты.

- Поощряйте и вознаграждайте повторное использование

- проектов,

- библиотек, и

- классов.

- Сосредоточьтесь на проектировании компоненты.

- Используйте классы для представления понятий.

- Определяйте интерфейсы так, чтобы сделать открытым минимальный

объем информации, требуемой для интерфейса.

- Проводите строгую типизацию интерфейсов всегда, когда это

возможно.

- Используйте в интерфейсах типы из области приложения всегда,

когда это возможно.

- Многократно исследуйте и уточняйте как проект, так и реализацию.

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

- проекта, и

- реализации.

- Экспериментируйте, анализируйте и проводите тестирование на

самом раннем возможном этапе.

- Стремитесь к простоте, максимальной простоте, но не сверх того.

- Не разрастайтесь, не добавляйте возможности "на всякий случай".

- Не забывайте об эффективности.

- Сохраняйте уровень формализации, соответствующим размеру проекта.

- Не забывайте, что разработчики, программисты и даже менеджеры

остаются людьми.

Еще некоторые правила можно найти в $$12.5

11.6 Список литературы с комментариями

В этой главе мы только поверхностно затронули вопросы проектирования

и управления программными проектами. По этой причине ниже предлагается

список литературы с комментариями. Значительно более обширный список

литературы с комментариями можно найти в [2].

[1] Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for

Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa,

Canada. pp. 12-27.

Описание модели итеративного проектирования и повторного

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

[2] Grady Booch: Object Oriented Design. Benjamin Cummings. 1991.

В этой книге есть детальное описание проектирования, определенный

метод проектирования с графической формой записи и несколько

больших примеров проекта, записанных на различных языках. Это

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

более глубоко рассматриваются многие из затронутых здесь вопросов.

[3] Fred Brooks: The Mythical Man Month. Addison Wesley. 1982.

Каждый должен перечитывать эту книгу раз в пару лет.

Предостережение от высокомерия. Она несколько устарела в

технических вопросах, но совершенно не устарела во всем, что

касается отдельного работника, организации и вопросов размера.

[4] Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4.

April 1987.

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

систем с очень полезным предостережением от веры в магические

рецепты ("золотая пуля").

[5] De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987.

Одна из немногих книг, посвященных роли человеческого фактора

в производстве программного обеспечения. Необходима для каждого

менеджера. Достаточно успокаивающая для чтения перед сном.

Лекарство от многих глупостей.

[6] Ron Kerr: A Materialistic View of the Software "Engineering"

Analogy. in SIGPLAN Notices, March 1987. pp 123-125.

Использование аналогии в этой и следующей главах во многом

обязано наблюдениям из указанной статьи, а так же беседам с

Р. Керром, которые этому предшествовали.

[7] Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87

(Addendum). Orlando, Florida. pp 17-34.

Исследуется как использование наследования может повредить

концепции абстрактных данных. Укажем, что в С++ есть специальные

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

проблем ($$12.2.5).

[8] C. N. Parkinson: Parkinson's Law and other Studies in

Administration. Houghton-Mifflin. Boston. 1957.

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

приводит процесс администрирования.

[9] Bertrand Meyer: Object Oriented Software Construction.

Prentice Hall. 1988.

Страницы 1-64 и 323-334 содержат хорошее описание одного взгляда

на объектно-ориентированное программирование и проектирование,

а также много здравых, практических советов. В остальной части

книги описывается язык Эйффель (Eiffel).

[10] Alan Snyder: Encapsulation and Inheritance in Object-Oriented

Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45.

Возможно первое хорошее описание взаимодействия оболочки и

наследования. В статье так же на хорошем уровне рассматриваются

некоторые понятия, связанные с множественным наследованием.

[11] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener:

Designing Object-Oriented Software. Prentice Hall. 1990.

Описывается антропоморфный метод проектирования основанный на

специальных карточках CRC (Classes, Responsibilities,

Collaboration) (т.е. Классы, Ответственность, Сотрудничество).

Текст, а может быть и сам метод тяготеет к языку Smalltalk.

* ПРОЕКТИРОВАНИЕ И С++

Стремись к простоте, максимальной простоте, но не сверх того.

- А. Эйнштейн

Эта глава посвящена связи между проектированием и языком

программирования С++. В ней исследуется применение классов при

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

следует выделять как внутри класса, так и между классами. Изучается

роль статического контроля типов. Исследуется применение наследования

и связь наследования и принадлежности. Обсуждается понятие компонента

и даются некоторые образцы для интерфейсов.