Б. Страуструп - Язык программирования С++. Специальное издание, 3-изд. Бином. 2004 (1160791), страница 175

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 175)

Упор на примерах использования, особенно у того, кто имеет опыт в структурном анализе и не имеет опыта в объектно-ориентированном программировании>>проектировании, ведет к функциональной декомпозиции. Набор примеров использования — это не проект. Фокусирование на использовании системы должно уравновешиваться анализом ее структуры.

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

Сколько нужно примеров? На этот вопрос нельзя ответить однозначно. Однако в каждом конкретном проекте приходит время, когда становится ясно, что большая часть обычного функционирования системы описана, а часть не столь обычного функционирования и обработки ошибок уже изучена. Значит, пора приступать к следуюшему этапу проектирования и программирования. Когда вы пытаетесь оценить процент покрытия системы набором примеров использования, полезно разделить примеры на первичные и вторичные, Первичные описывают наиболее общие и «нормадьные> действия, а вторичные — необычные действия и сценарии обработки ошибок. Примером вторичного примера использования может послужить вариант с телефонным звонком, когда номер занят, и оттуда звоня~ на этот конец.

Часто говорят, что когда покрыто 80>«первичных и несколько вторичных примеров, сбор примеров пора заканчивать, но поскольку мы заранее ис знаем, что такое 100;>«, это просто эмпирическое приближенное правило. Тут много значат опыт и хороший вкус. Упомянутые здесь концепции, операции и взаимосвязи есгественно вытекаю~ из нашего понимания области применения или появляются при дальнейшей работе над структурой классов.

Они представляют собой наше фундаментальное понимание приложения. Час~о они являются классификацией фундаментальных концепций. Например, «машина с раздвижной лестницей > является частным случаем пожарной машины, которая представляет собой разновидность грузовика, который, в свою очередь, представляет собой разновидность транспортного средства вообще.

Подразделы э 23А.3.2 и б 23А.5 знакомят с несколькими способами взгляда на классы и иерархию классов с точк>и зрения их улучшения. Опасайтесь наглядных схем! На определенной стадии вас попросят познакомить кого-нибудь с проектом, и вы выдадите набор диаграмм, объясняющих структуру строящейся системы. Это может оказаться очень полезным упражнением, поскольку помо- 775 23.4. Процесс разработки жет сосредоточить внимание на том, что в системе важно, н застав»и выразизь свои идеи в терминах, понятных для других.

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

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

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

Врожденные свойства системы можно определить, их можно закладывать в проект и в конце концов проверять измерением. Забота об этих свойствах должна красной нитью проходить через все классы, и ее можно отразить в правилах проектирования и реализации для отдельных классов и компонент. 23.4.3.2. Этап 2: определение операций Уточните классы, определив набор операций яад ними.

Естественно, невозможно отделить выявление классов от выяснения того, какие операции понадобятся. Однако практический метод состоит в том, что поиск классов сосредотачивается на ключевых концепциях и преднамеренно не делает упора на операциях, в то время как определение операций фокусируется на нахождении полного и удобного для применения набора действий. Очень часто слишком трудно рассматривать и то, и другое одновременно, особенно когда родственные классы нужно разрабатывать вместе. Когда приходит время рассматривать и то, и другое, часто оказываются полезными СВС-карточки (з 23А.З).

При выяснении того, какие функции надо обеспечить, можно высказать несколько общих соображений. Я предлагаю следующую стратегию: [1) Подумайте, как объект класса должен конструироваться, копироваться (если должен) и уничтожаться. [2] Определите хщнциальяый набор операций, которые требует представляющая класс концепция. Как правило, эти операции становятся функциями-членами Я 10.3).

776 Глава 23. Разработка и проектирование [3) Подумайте, какие операции можно добавить для удобства. Включите только несколько действительно важных. Часто эти операции становятся не членами, а «функциями-помошниками» Я 10.3.2). 14) Подумайте, какие операции должны быть виртуальными — то есть операциями, для которых класс может действовать как интерфейс реализации, обеспечиваемой производным классом. Я Подумайте, какой общности в именовании и функциональности можно достичь для всех классов компоненты.

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

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

Характеристики

Список файлов книги