» Главная
eXcode.ru » Статьи » Другие » Основы объектно-ориентированного проектирования
» Новости
» Опросы
» Файлы
» Журнал



Пользователей: 0
Гостей: 11





Ведущий раздела: MadvEX
Описание: Фундаментальный учебник по основам объектно-ориентированного проектирования и инженерии программ. В книге подробно рассматривается объектная технология бесшовной разработки программных систем, включающая этапы анализа, проектирования, разработки и сопровождения. Как находить классы, правильное использование наследования, таксономия наследования, объектно-ориентированный анализ – это далеко не полный перечень рассматриваемых в книге тем. (Источник: www.intuit.ru Авторы: Мейер Бертран)



«1» «2» 

Объектно-ориентированная методология
В этих лекциях рассматривается методология объектной ориентации: как применять мощное множество концепций и технических приемов для получения преимуществ наших проектов и успешной их организации.


Образец проектирования
Создадим образец проектирования, иллюстрирующий ОО-метод. Он будет сравниваться с другими подходами, в частности с функциональной декомпозицией сверху вниз, что позволит продемонстрировать выдающиеся возможности Метода. Поскольку этот пример, имея небольшой размер, прекрасно охватывает принципиальные свойства конструирования ОО-ПО, я часто использую его, когда необходимо в течение нескольких часов познакомить аудиторию с возможностью Метода. Показывая на практике (даже для людей с весьма слабой математической подготовкой), как каждый может перейти от классической декомпозиции к ОО-взгляду на вещи, и преимущества, получаемые в результате такого перехода, наш пример является замечательным педагогическим средством. Читателям еще в начале книги предлагалось прочесть эту лекцию, представляющую "рекламный ролик" ОО-метода проектирования. Для облегчения задачи она написана как можно более независимо. Если эта лекция читается после изучения предыдущих лекций, то вы встретите некоторые повторения, в частности несколько коротких определений уже знакомых концепций.


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


Как найти классы
Важнейшая цель ОО-методологии - дать рекомендации по нахождению классов, на основе которых строится программная система. Этому посвящена данная лекция. Предупреждаю, не следует ожидать слишком многого. Поиск классов - это одна из центральных проблем при ОО-конструировании ПО. Как в любой творческой деятельности ее решение определяется талантом и опытом, не исключая и доли везения. Нереально ожидать безошибочных рецептов по поиску классов, как нельзя ожидать рецептов, позволяющих математику создавать новые теории или находить доказательства теорем. Хотя оба вида деятельности - конструирование ПО и конструирование теорий - могут извлекать пользу от советов общего вида и опыта удачливых предшественников, но в обоих случаях требуется созидательная работа, не регламентируемая механическими правилами. Если, как и многие в программной индустрии, вы полагаете, что эти два вида деятельности нельзя сравнивать, то рассматривайте нашу работу просто как одну из форм инженерного проектирования, хотя здесь и можно дать базисное руководство, но никакие придуманные пошаговые правила не могут гарантировать хорошего проектирования новых самолетов или мостов. При проектировании ПО никакие книги не могут заменить вашей интуиции и владения тем, что называется "ноу-хау" (know-how). Роль методологического обсуждения состоит в том, чтобы указать на хорошие идеи, привлечь внимание к удачным прецедентам и предупредить о типичных ловушках. Это относится к любому методу проектирования. В объектном случае есть некоторые хорошие новости, приходящие в форме повторного использования. Поскольку многое из необходимого уже изобретено, можно начинать строить, используя достижения других разработчиков. Есть и другие хорошие новости. Начиная со скромных притязаний, но внимательно изучив, что работает, а что нет, двигаясь мало-помалу в исключительно неблагоприятных условиях, мы получим возможность изобрести нечто, заслуживающее название метода поиска классов. Как всегда при поиске кандидатов, метод отбора включает два компонента - набор абитуриентов и их последующий отсев.


Принципы проектирования класса
Опытные разработчики ПО знают, что одной из наиболее критичных проблем является проблема проектирования интерфейсов модуля. В больших и длительных проектах многие обсуждения и недоразумения связаны со спецификациями интерфейса модулей: "Но я полагал, что вы передаете мне уже нормализованные данные...", "Зачем Вы делаете эту обработку, я ведь уже об этом позаботился?.." и так далее. Если от объектной технологии ожидать только одного преимущества, то следовало бы указать на проектирование интерфейсов. В самом начале мы определяли ОО-технологию как архитектурную технику производства программных систем, построенных из модулей, согласованных по интерфейсу. Теперь у нас есть техническая база, позволяющая пользоваться наилучшими ОО-механизмами для построения модулей с привлекательными интерфейсами. Поскольку успех класса определяется тем, насколько он привлекателен для своих клиентов, то наше внимание будет уделяться не столько внутренней реализации, а тому, насколько прост его интерфейс, легок в обучении, прост для запоминания, способен выдержать проверку временем и изменениями. В задачу нашего исследования входит ряд важных вопросов: должны ли функции допускать побочные эффекты, много ли аргументов должно быть у компонентов, чем отличаются связанные понятия операнда и опции (option), следует ли сосредоточиваться на размерах класса, как сделать абстрактные структуры активными, роль выборочного экспорта, как документировать класс, что делать в особых случаях? Из нашего обсуждения будет ясно, что проектировщик класса должен как опытный мастер довести свое изделие до совершенства, полируя до блеска, делая его привлекательным для клиентов, насколько это только возможно. Этот дух рассмотрения классов как тщательно сработанных инженерных изделий, совершенных по замыслу, исполнению и всегда остающимися таковыми, является всеобъемлющим качеством хорошо определенной объектной технологии. По очевидным причинам он особенно проявляется при конструировании библиотек классов. Оригинальные конструкторские разработки вначале проверяются на машинах, участвующих в гонках Formula 1, прежде чем они станут достоянием автомобильной промышленности. Доказав применимость при разработке успешной библиотеки повторно используемых компонентов, рассматриваемые идеи обеспечат преимущество и любому ОО-ПО независимо от того, предполагалось ли его повторное использование с самого начала.


Используйте наследование правильно
Изучение технических деталей наследования и связанных механизмов в лекциях 7-18 курса "Основы объектно-ориентированного программирования" не означает еще автоматического владения всеми методологическими следствиями. Из всех проблем ОО-технологии ни одна не вызывает столько обсуждений и вопросов о том, как и когда использовать наследование. В этой лекции мы продвинемся в понимании смысла наследования не ради теории, а ради наилучшего применения наследования в наших проектах. В частности, мы попытаемся понять, чем наследование отличается от другого межмодульного отношения, его брата и соперника, - отношения встраивания, чаще всего называемого клиентским отношением. Мы исследуем, когда следует использовать одно, когда - другое, а когда оба отношения являются приемлемыми. Мы установим основной критерий использования наследования, по пути выяснив, в каких случаях его использование ошибочно. Мы сможем создать классификацию различных случаев легитимного использования, часть из которых принимается безоговорочно (наследование подтипов), другие - более спорны. На этом пути мы попытаемся освоить опыт таксономии или систематики, привнесенный из других научных дисциплин.


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


Чувство стиля
Реализация ОО-метода требует обращать внимание на многие детали стиля, считающиеся пустяковыми для менее амбициозного подхода.


Объектно-ориентированный анализ
Направленный изначально на решение проблем реализации ОО-метод быстро распространился на весь жизненный цикл ПО. Особый интерес представляет приложение ОО-идей к моделированию как программных, так и непрограммных систем. Это применение объектной технологии для рассмотрения скорее проблем, чем решений, известно как объектно-ориентированный анализ. В последние годы появилось много книг по данной тематике, предложены специальные методы ОО-анализа. В разделе библиографии перечислены наиболее известные книги и ссылки на ресурсы Интернета для ряда популярных методов. Большинство концепций, представленных в предыдущих лекциях, имеет непосредственное отношение к ОО-анализу. В этой лекции мы рассмотрим особую роль объектного анализа и его отличия от других способов анализа. Для устранения несущественных различий необходимо отметить два терминологических момента. Во-первых, в качестве синонима понятия "анализ" используется термин системное моделирование или просто моделирование. Во-вторых, при обсуждении анализа в компьютерном сообществе существует тенденция использовать слово спецификация. В частности, специалисты направили значительные усилия на разработку методов и языков формальной спецификации, используя математические методы для системного моделирования. При единстве целей подходы могут отличаться. В последние годы два сообщества - разработчиков моделей и формальных спецификаций - стали обращать больше внимания на деятельность друг друга.


Процесс разработки ПО
Центральный вопрос объектной технологии - ее воздействие на весь процесс разработки ПО. Пришло время рассмотреть влияние ОО-принципов на общую организацию проектов и их деление на этапы. Это часть более общей проблемы перспектив объектной технологии с позиций менеджмента. Вопросы менеджмента подробно изучаются в книге Object Success. В данной лекции обсуждаются лишь наиболее существенные идеи: кластеры как основная организационная единица, принципы параллельной разработки на основе кластерной модели жизненного цикла ПО, этапы и задачи такой модели, роль обобщения для повторного использования, принципы бесшовности и обратимости.


«1» «2» 

Имя:

Пароль:



Регистрация

Какую БД предпочитаете?
MSSQL
20% (38)
BDE
1% (1)
MySQL
35% (68)
Access
6% (11)
InterBase
11% (21)
Paradox
3% (5)
Oracle
10% (19)
PostgreSQL
0% (0)
Другой
3% (6)
Не использую БД!
12% (23)

Проголосовало: 192
Программисты фирмы "Майкрософт" нашли действенное решение по устранению "синих экранов смерти" в операционной системе Windows. С официального сайта Вы можете скачать официальный патч. Теперь в "Панели управления" можно выбрать любой другой цвет для этого режима. А в будущих версиях ОС планируется возможность выбора фоновой картинки на свой вкус.
Рейтинг: 9.3/10 (46)
Посмотреть все анекдоты