Объектно-ориентированный подход. Объектно_ориентированный_подход. Объектно ориентированный подход Мэтт Вайсфельд 5е международное издание ббк 32. 973. 2018
 Скачать 5.43 Mb.
|
|
Руководство по проектированию Ошибочно полагать, что может быть одна истинная методология проектиро- вания. На самом деле это, конечно же, не так. Нет правильного или неправиль- Глава.6..Проектирование.с.использованием.объектов 124 ного способа проектирования. Сегодня доступно много методологий, и у каждой из них имеются свои сторонники. Однако главный вопрос состоит не в том, какую методику проектирования использовать, а в том, применять ли ту или иную методику вообще. Все это можно вывести за пределы проектиро- вания, чтобы охватить весь процесс разработки программного обеспечения. Многие организации не соблюдают стандартный процесс разработки про- граммного обеспечения либо выбирают какой-то один, но не придерживаются его твердо. При грамотном подходе к проектированию самое главное — вы- яснить, какой процесс кажется вам и вашей организации удобным, и придер- живаться его. Нет смысла внедрять процесс проектирования, который никто не будет соблюдать. Большинство книг, в которых рассматриваются объектно-ориентированные технологии, предлагает очень схожие стратегии проектирования систем. Фак- тически, за исключением некоторых из затрагиваемых специфических объектно- ориентированных вопросов, многое из стратегий также применимо к не объ- ектно-ориентированным системам. Как правило, надлежащий процесс объектно-ориентированного проектирования включает следующие этапы. 1. Проведение соответствующего анализа. 2. Составление технического задания, описывающего систему. 3. Сбор требований исходя из составленного технического задания. 4. Разработка прототипа интерфейса пользователя. 5. Определение классов. 6. Определение ответственности каждого класса. 7. Определение того, как разные классы будут взаимодействовать друг с дру- гом. 8. Создание высокоуровневой модели, описывающей систему, которую требу- ется построить. В сфере объектно-ориентированной разработки высокоуровневая модель пред- ставляет особый интерес. Систему или объектную модель образуют диаграммы и взаимодействия классов. Эта модель должна точно представлять систему и быть легкой для понимания и модификации. Кроме того, необходима нотация для модели. Именно здесь в дело вступает унифицированный язык моделиро- вания — Unified Modeling Language (UML). Как вы уже знаете, UML — это не процесс проектирования, а средство моделирования. В данной книге я сосредо- точиваюсь только на диаграммах классов в рамках UML. Мне нравится исполь- зовать диаграммы классов в качестве визуального средства, которое помогает при проектировании и документировании, даже если я не использую остальные доступные средства UML. 125 Руководство.по.проектированию. . ПОСТОЯННЫЙ ПРОЦЕСС ПРОЕКТИРОВАНИЯ __________________________________________ Несмотря.на.тщательное.планирование,.почти.во.всех.случаях.проектирование.ока- зывается.постоянным.процессом..Даже.после.того,.как.продукт.будет.протестирован,. неожиданно.возникнет.необходимость.внести.конструктивные.изменения..Менеджер. проекта.должен.решить,.где.провести.границу,.которая.укажет,.когда.следует.перестать. вносить.изменения.в.продукт.и.добавлять.функции..Я.называю.это.«Версия.1». Важно осознавать, что сейчас доступно множество методологий проектирования. Одна из первых методологий, называемая моделью водопада, предполагает установление точных границ между разными стадиями. При этом стадия про- ектирования должна завершиться до стадии реализации, которая, в свою очередь, должна быть завершена до стадии тестирования и т. д. На практике модель водопада была признана нереалистичной. В настоящее время другие модели проектирования, например быстрое прототипирование, экстремальное про- граммирование, гибкая разработка, Scrum и пр., пропагандируют истинный итеративный процесс. В этих моделях в качестве своего рода эксперимента предпринимается попытка пройти часть стадии реализации еще до завершения стадии проектирования. Несмотря на нынешнюю антипатию к модели водо- пада, цель этой модели понятна. Полностью и тщательно спроектировать все до начала написания кода — это рациональный подход. Наверняка вы не захотите снова пройти стадию проектирования, находясь на стадии выпуска продукта. Итерации с пересечением границ между стадиями неизбежны, однако вам сле- дует сводить их к минимуму (рис. 6.1). Рис. 6.1. Метод.водопада Глава.6..Проектирование.с.использованием.объектов 126 Попросту говоря, можно назвать следующие причины для заблаговременного определения требований и сведения конструктивных изменений к минимуму. Издержки из-за изменений требований / конструктивных правок на стадии проектирования будут сравнительно невелики. Издержки из-за конструктивных изменений на стадии реализации будут значительно выше. Издержки из-за конструктивных изменений после завершения стадии раз- вертывания будут астрономическими по сравнению с теми, что упоминались в первом пункте. Аналогичным образом, вы не захотите начинать строительство дома своей меч- ты до того, как будет завершено архитектурное проектирование. Если я заявлю, что мост «Золотые Ворота» или небоскреб «Эмпайр-стейт-билдинг» были по- строены без предварительного решения каких-либо задач проектирования, то вы решите, что это высказывание абсолютно безумно. Вместе с тем вы, скорее всего, не посчитаете мои слова глупыми, если я скажу вам, что используемое вами программное обеспечение может содержать конструктивные недостатки и, возможно, на самом деле не было тщательно протестировано. В действительности может получиться так, что невозможно тщательно про- тестировать программное обеспечение, чтобы выявить абсолютно все дефекты. Однако в теории к этому следует стремиться. Вы должны всегда стараться устранить как можно больше имеющихся дефектов. Мосты и программное обеспечение, возможно, нельзя сравнивать напрямую, однако при работе с про- граммным обеспечением нужно стремиться к тому же уровню конструктор- ского совершенства, что и в более «сложных» инженерных отраслях вроде строительства мостов. Использование программного обеспечения низкого качества может привести к фатальным последствиям — здесь имеются в виду не просто неправильные цифры на чеках по расчету заработной платы. На- пример, плохое программное обеспечение, заложенное в медицинское обо- рудование, может убить или покалечить людей. Кроме того, вы, возможно, будете готовы смириться с необходимостью время от времени перезагружать свой компьютер. Однако нельзя сказать то же самое, если речь идет об угрозе обрушения моста. БЕЗОПАСНОСТЬ В ПРОТИВОПОСТАВЛЕНИИ С ЭКОНОМИКОЙ ________________________ Вы.хотели.бы.перейти.через.мост,.который.не.был.тщательно.испытан?.К.сожалению,. во.многих.программных.пакетах.на.пользователей.возлагается.обязанность.по.вы- полнению.значительной.части.тестирования..Это.обходится.очень.дорого.как.поль- зователям,.так.и.поставщикам.программного.обеспечения..К.сожалению,.похоже,. что.краткосрочно.ориентированная.экономика.зачастую.оказывается.главным. фактором.при.принятии.решений.о.проектах. 127 Руководство.по.проектированию. . Поскольку клиенты, по-видимому, согласны платить ограниченную цену и ми- риться с программным обеспечением низкого качества, некоторые поставщики ПО считают, что в долгосрочной перспективе будет дешевле позволять заказ- чикам тестировать продукт, нежели самим заниматься этим. Это, возможно, и верно, если говорить о ближайшей перспективе, однако в долгосрочной пер- спективе это обойдется намного дороже. В конечном счете пострадает репутация самих поставщиков. Некоторые компании — производители программного обеспечения предпочи- тают проводить стадию бета-тестирования и тем самым дать возможность клиентам провести тестирование. Такое тестирование теоретически должно было проводиться до того, как бета-версия дойдет до клиента. Многие клиенты не так озадачены рисками при использовании предварительной версии, как стремятся получить функциональность новейшей версии. Напротив, некоторые клиенты до последнего избегают перехода на новые версии, следуя принципу «не чини то, что работает». Для них обновление — это сплошной кошмар. После того как программное обеспечение будет выпущено, решение проблем, которые не были выявлены и устранены до выпуска продукта, обойдется на- много дороже. В качестве наглядного примера возьмем дилемму, перед кото- рой стоят автомобильные компании, столкнувшиеся с необходимостью ото- звать из продажи свою продукцию. Если дефект в автомобилях будет выявлен и устранен до того, как они поступят в продажу, то это обойдется значитель- но дешевле, чем если все доставленные автомобили придется отзывать и ре- монтировать поодиночке. Этот сценарий не только дорого обойдется, но и нанесет урон репутации компании. На рынке с постоянно растущей конку- ренцией важно выпускать высококачественное программное обеспечение (рис. 6.2). Рис. 6.2. Конкурентное.преимущество Глава.6..Проектирование.с.использованием.объектов 128 В последующих разделах кратко рассматриваются этапы процесса проектиро- вания. Позднее в этой главе мы взглянем на пример, который подробнее объ- ясняет каждый из этих этапов. Проведение соответствующего анализа В проектирование и производство того или иного программного продукта во- влечено много переменных факторов. Пользователи должны действовать рука об руку с разработчиками на всех стадиях. На стадии анализа пользователям и разработчикам необходимо провести соответствующее исследование и анализ, чтобы определить техническое задание, требования к проекту и понять, следу- ет ли вообще заниматься этим проектом. Последний пункт может показаться немного неожиданным, однако он важен. На стадии анализа нужно без всяких колебаний прекратить работу над проектом, если выяснится, что на то есть вес кая причина. Слишком часто бывает так, что статус любимого проекта или некая политическая инертность способствуют поддержанию жизни в проекте вопреки очевидным предупреждающим знакам, которые «кричат» о необходи- мости его отмены. Если проект жизнеспособен, то основное внимание всех его участников на стадии анализа должно быть сосредоточено на изучении систем (как старой, так и предлагаемой новой), а также на определении системных требований. ОБЩИЕ ПРИНЦИПЫ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ __________________ Большинство.этих.методик.нехарактерны.для.объектно-ориентированной.разработ- ки..Они.относятся.к.разработке.программного.обеспечения.в.целом. Составление технического задания Техническое задание — документ, описывающий систему. Хотя определение требований — это конечная цель стадии анализа, на данном этапе они еще не обретают свою финальную форму. Техническое задание должно обеспечить полное понимание системы для любого человека, прочитавшего этот документ. Независимо от того, как оно будет составлено, техническое задание должно представлять полную систему и ясно описывать то, как система будет выглядеть. Техническое задание содержит всю информацию, что следует знать о системе. Многие заказчики готовят заявку на проект для распространения, которая схожа с техническим заданием. Заказчик формирует заявку на проект, полно- стью описывающую систему, создание которой ему необходимо, и распростра- няет эту заявку среди большого количества поставщиков. Поставщики затем используют этот документ при любом анализе, который им потребуется про- вести, чтобы выяснить, следует ли им браться за этот проект, и, если да, то какую цену назначить за его выполнение. 129 Руководство.по.проектированию. . Сбор требований Документ с требованиями описывает, что, по мнению пользователей, должна делать система. Необязательно излагать требования на высоком техническом уровне, но они должны быть достаточно конкретными для того, чтобы можно было понимать потребности пользователя в конечном продукте. Документ с требованиями должен быть достаточно подробным, чтобы пользователь затем смог вынести обоснованное решение о полноте системы. В то время как техническое задание пишется с разделением на абзацы (или даже в повествовательной форме), требования обычно представляются в виде краткой сводки либо маркированного списка. Каждый пункт списка представляет одно определенное требование к системе. Требования «извлекаются» из техническо- го задания. Этот процесс будет продемонстрирован позднее в текущей главе. Во многих отношениях эти требования являются наиболее важной частью си- стемы. Техническое задание может содержать не относящуюся к делу инфор- мацию, а требования — это итоговое представление системы, которое должно быть претворено в жизнь. Все будущие документы в процессе разработки про- граммного обеспечения будут базироваться на этих требованиях. Разработка прототипа интерфейса пользователя Один из наилучших способов убедиться в том, что пользователям и разработ- чикам понятна система, — создать прототип. Прототип может быть практически всем, чем угодно, однако большинство людей рассматривают его как имитацию интерфейса пользователя. Увидев фактические экраны и их последовательности, люди быстрее поймут, с чем им предстоит работать и как будет выглядеть си- стема. Так или иначе, прототип почти наверняка не будет содержать всю функ- циональность итоговой системы. Большинство прототипов создается с помощью той или иной интегрированной среды разработки. Visual Basic .NET традиционно является хорошей средой для прототипирования, хотя в настоящее время для этого также используются дру- гие языки программирования. Помните, что вам необязательно создавать биз- нес-логику (логику, которая лежит в основе интерфейса и в действительности выполняет всю работу) при построении прототипа, хотя это возможно. На данном этапе главная забота — внешний вид интерфейса пользователя. Наличие прототипа может очень помочь при определении классов. Определение классов После того как требования будут задокументированы, вы сможете начать про- цесс определения классов. Если брать за основу требования, то самый простой способ определить классы — выделить все существительные. Они представляют Глава.6..Проектирование.с.использованием.объектов 130 людей, места и вещи. Не слишком беспокойтесь насчет того, чтобы определить сразу все классы. Может получиться так, что вам придется удалять, добавлять и изменять классы на разных стадиях всего процесса проектирования. Важно сначала что-нибудь написать. Помните, что проектирование является итератив- ным процессом. Как и в случае с другими формами мозгового штурма, писать изначально следует с осознанием того, что итоговый результат может быть аб- солютно не похож на то, как все представлялось в самом начале. Определение ответственности каждого класса Вам потребуется определить ответственность каждого созданного ранее класса. Сюда входят данные, которые должен содержать класс, а также операции, ко- торые он должен выполнять. Например, объект Employee отвечает за расчет заработной платы и перевод денег на соответствующий счет. Он также может отвечать за хранение таких данных, как разные уровни оплаты труда и номера счетов в различных банках. Определение взаимодействия классов друг с другом Большинство классов не существуют в изоляции. Хотя класс должен нести определенную ответственность, ему неоднократно придется взаимодействовать с другими классами, чтобы получить требуемое. Именно здесь находят свое применение сообщения между классами. Один класс может отправить сообще- ние другому, когда ему нужна информация из этого класса либо требуется, чтобы другой класс что-то сделал для него. Создание модели классов для описания системы Когда все классы, их ответственность и взаимодействия будут определены, вы сможете приступить к конструированию модели классов, представляющей полную систему. Модель классов показывает, как разные классы взаимодей- ствуют в рамках системы. В этой книге для моделирования системы мы используем UML. На рынке мож- но найти несколько инструментов, которые задействуют UML и обеспечивают хорошую среду для создания и сопровождения моделей классов UML. По мере рассмотрения примера в следующем разделе мы увидим, как диаграммы классов вписываются в общую картину и почему моделирование больших систем будет фактически невозможным без хорошей нотации. Прототипирование интерфейса пользователя Во время проектирования нам потребуется создать прототип нашего интерфей- са пользователя. Этот прототип будет предоставлять бесценную информацию, 131 Объектные.обертки. . которая поможет в навигации по итерациям процесса проектирования. Как удачно подметили Гилберт и Маккарти в книге «Объектно-ориентированное проектирование на Java», «для пользователя системы пользовательский интер- фейс является системой». Есть несколько способов создания прототипа интер- фейса пользователя. Вы можете сделать набросок интерфейса на бумаге или на лекционной доске либо воспользоваться специальным инструментом прототи- пирования или даже языковой средой вроде Visual Basic, которая часто при- меняется для быстрого прототипирования. Кроме того, вы можете прибегнуть к интегрированной среде разработки из вашего любимого средства разработки для создания прототипа. Однако при разработке прототипа интерфейса пользователя позаботьтесь о том, чтобы у пользователей было право окончательного решения по поводу его внешнего вида. Объектные обертки В предыдущих главах я несколько раз отмечал, что одна из моих основных целей в этой книге — развеять миф, согласно которому объектно-ориентированное программирование является парадигмой, отдельной от структурного програм- мирования, и даже противоречит ему. Более того, как я уже отмечал ранее, мне часто задают следующий вопрос: «Вы занимаетесь объектно-ориентированным или структурным программированием?» Ответ всегда звучит одинаково: «Я за- нимаюсь и тем и другим!» Я считаю, что писать программы без использования структурированного кода невозможно. Таким образом, когда вы пишете программу на объектно-ориен- тированном языке и используете соответствующие методики объектно-ориен- тированного проектирования, вы также пользуетесь методиками структурного программирования. Это неизбежно. Например, когда вы создадите новый объект, содержащий атрибуты и методы, эти методы будут включать структурированный код. Фактически я даже могу сказать, что эти методы будут содержать в основном структурированный код. Этот подход соответствует контейнерной концепции, с которой мы сталкивались в предыдущих главах. Кроме того, когда я подхожу к точке, в которой пишу код на уровне методов, мое мышление программиста незначительно меняется по сравнению с тем моментом, когда я программировал на структурных языках, например COBOL, C и т. п. Я не хочу сказать, что оно остается точно таким же, поскольку мне, несомненно, приходится привыкать к кое-каким объектно-ори- ентированным концепциям. Но основной подход к написанию кода на уровне методов практически не меняется. Теперь я вернусь к вопросу: «Вы занимаетесь объектно-ориентированным или структурным программированием?» Я люблю говорить, что программирование — |