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.

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

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