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



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





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



«1» «2» 

Качество ПО
Качество - это цель инженерной деятельности; построение качественного ПО (software) - цель программной инженерии (software engineering). В данной книге рассматриваются средства и технические приемы, позволяющие значительно улучшить качество ПО. Прежде чем приступить к изучению этих средств и приемов, следует хорошо представлять нашу цель. Качество ПО лучше всего описывается комбинацией ряда факторов. В этой лекции мы постараемся проанализировать некоторые из них, покажем, где необходимы улучшения, и укажем дорогу в дальнейшем путешествии по лекциям этого курса.


Критерии объектной ориентации
В предыдущей лекции исследовались цели ОО-метода. Готовясь к чтению технических деталей метода в следующих лекциях, полезно быстро, но с широких позиций рассмотреть ключевые аспекты ОО-разработки ПО. Такова цель этой лекции. Прежде всего, здесь будет дано лаконичное пояснение того, что делает систему объектно-ориентированной. Уже в этом есть определенная польза, поскольку этот термин используется так неразборчиво, что необходим список точных свойств; имея их, мы сможем оценить метод, язык или инструмент, претендующие на звание объектно-ориентированных. Ограничимся минимумом объяснений, поэтому при первом чтении нельзя надеяться на понимание деталей всех перечисленных критериев; объяснение их - задача остальных разделов книги. Можно считать это обсуждение предваряющим просмотром - не настоящим кино, а анонсом. В отличие от анонса, эта лекция скорее является так называемым спойлером (spoiler) - она пересказывает сюжет, нарушая порой общий план книги. Этим она отличается от других лекций, в особенности лекций 3-6, терпеливо выстраивающих объектную технологию, рассматривающих проблему за проблемой на пути к получению и обоснованию решения. Если вам нравится идея обзора, предшествующая глубокому изучению вопросов, эта лекция для вас. Но если вы предпочитаете не портить удовольствия, открывая решения одно за другим, то просто пропустите ее.


Модульность
В лекциях 3-6 будут рассмотрены требования к разработке программного продукта, которые почти наверняка приведут нас к объектной технологии. Чтобы обеспечить расширяемость (extendibility) и повторное использование (reusability), двух основных факторов качества, предложенных в лекции 1, необходима система с гибкой архитектурой, состоящая из автономных программных компонент. Именно поэтому в лекции 1 введен термин модульность (modularity), сочетающий оба фактора. Модульное программирование ранее понималось как сборка программ из небольших частей, обычно подпрограмм. Но такой подход не может обеспечить реальную расширяемость и повторное использование программного продукта, если не гарантировать, что элементы сборки - модули - являются самодостаточными и образуют устойчивые структуры. Любое достаточно полное определение модульности должно обеспечивать реализацию этих свойств. Таким образом, метод проектирования программного продукта является модульным, если он помогает проектировщикам создать систему, состоящую из автономных элементов с простыми и согласованными структурными связями между ними. Цель этой лекции - детализация этого неформального определения и выяснение того, какими конкретно свойствами должен обладать метод, заслуживающий название "модульного". Наше внимание будет сосредоточено на этапе проектирования, но все идеи применимы и к ранним этапам - анализа и спецификации, также как и к этапам разработки и сопровождения. Рассмотрим модульность с разных точек зрения. Введем набор дополнительных свойств: пять критериев (criteria), пять правил (rules) и пять принципов (principles) модульности, обеспечивающих при их совместном использовании выполнение наиболее важных требований, предъявляемых к методу модульного проектирования. Для практикующего разработчика ПО принципы и правила не менее важны, чем критерии. Различие лишь в причинной связи: критерии являются взаимно независимыми (метод может удовлетворять одному из них и в тоже время противоречить оставшимся), в то время как правила следуют из критериев, а принципы следуют из правил. Можно было бы ожидать, что эта лекция начнется с подробного описания того, как выглядит модуль. Но это не так, и для этого есть серьезные основания. Задача этой и двух следующих лекций - анализ свойств, которыми должна обладать надлежащим образом спроектированная модульная структура. Вопросом о виде модулей мы займемся в конце нашего обсуждения, а не в его начале. И пока мы не дойдем до этой точки, слово "модуль" будет означать компонент разбиения рассматриваемой системы. Если вы знакомы с не ОО-методами, то, вероятно, вспомните о подпрограммах, имеющихся в большинстве языков программирования и проектирования, или, быть может, о пакетах (packages) языка Ada и (правда, под другим названием) языка Modula. Наконец, в последующих лекциях наше обсуждение приведет к ОО-виду модуля - классу. Даже если вы уже знакомы с классами и ОО-методами, все же следует прочитать эту лекцию для понимания требований, предъявляемых к классам, - это поможет правильному их конструированию.


Подходы к повторному использованию
"Последуйте примеру проектирования компьютерных технических средств! Это неверно, что каждая новая программная разработка должна начинаться с чистого листа. Должны существовать каталоги программных модулей, такие же, как каталоги сверхбольших интегральных схем СБИС (VLSI devices). Создавая новую систему, мы должны заказывать компоненты из этих каталогов и собирать систему из них, а не изобретать каждый раз заново колесо. Создавая меньше новых программ, мы, возможно, найдем лучшее применение своим усилиям. И, может быть, исчезнут некоторые из трудностей, на которые все жалуются - большие затраты, недостаточная надежность. Разве не так?" Вы, вероятно, слышали или даже сами высказывали такого рода замечания. Еще в 1968 г. на известной конференции НАТО по проблемам разработки ПО, Дуг Мак-Илрой (Doug McIlroy) пропагандировал идею "серийного производства компонентов ПО". Таким образом, мечта о возможности повторного использования программных компонентов не является новой. Было бы нелепо отрицать, что повторное использование имеет место в программировании. Фактически одним из наиболее впечатляющих результатов развития индустрии ПО с тех пор, как в 1988 г. появилось первое издание этой книги, явилось постепенное появление повторно используемых компонентов. Они получали все большее распространение, начиная от небольших модулей, предназначенных для работы с Visual Basic (VBX) фирмы Microsoft и OLE 2 (OCX, а сейчас ActiveX), до обширных библиотек классов, известных также как "каркасы приложений" ("framework applications"). Еще одним замечательным достижением является развитие Интернета: пришествие общества, охваченного Сетью (wired society), облегчило или в ряде случаев устранило некоторые из логических препятствий, казавшихся почти непреодолимыми еще несколько лет назад. Но это только начало. Мы далеки от предвидения Мак-Илроя о превращении программной инженерии в отрасль промышленности, основанную на использовании программных компонентов. Однако методология конструирования ОО-ПО впервые дала возможность представить себе практическую реализацию этого предвидения. И это может принести весьма значительную пользу не только разработчикам ПО, но, что еще важнее, тем, кто нуждается в их продукции, своевременно появляющейся и высококачественной. В этой лекции будут рассмотрены некоторые из проблем, направленных на широкомасштабное внедрение повторного использования программных компонентов.


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


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


Статические структуры
Анализируя основы программной инженерии, мы поняли причины, требующие совершенствования модульного подхода - повторное использование и расширяемость кода. Мы осознали, что традиционные методы исчерпали себя, - централизованная архитектура ограничивает гибкость. Мы выявили хорошую теоретическую основу ОО-подхода - абстрактные типы данных. Теперь, когда проблемам уделено достаточно внимания, вперед к их решению! Раздел C содержит введение в фундаментальные методы ОО-анализа, проектирования и программирования. Необходимые обозначения (элементы описания) будут вводиться по мере необходимости. Сначала необходимо рассмотреть базовые строительные блоки - классы.


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


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


Универсализация
Слияние двух концепций - модуля и типа - позволило разработать мощное понятие класса, послужившее основой ОО-метода. Уже в таком виде оно позволяет делать многое. Однако для достижения наших целей - расширяемости, возможности повторного использования, надежности необходимо сделать конструкцию класса более гибкой. Развитие может идти в двух направлениях. Один, представленный вертикалью на следующем рисунке, показывает абстракцию и специализацию; он ведет к изучению наследования в последующих лекциях. В данной лекции изучается другая размерность (горизонталь на рисунке), параметризация (тип как параметр), известная также как универсализация.


«1» «2» 

Имя:

Пароль:



Регистрация

В какой обстановке Вы программируете?
.. с пивом и друзьями ночью
9% (16)
.. без пива, но с друзьями
2% (3)
.. с кофеваркой в обнимку
23% (40)
.. с мешком чего-нибудь хрустящего
15% (27)
.. один, но с Rammstein ..
51% (89)

Проголосовало: 175
Один программист сделал очень эротическую программу с помощью всего лишь быстрого вводa - вывода.
Рейтинг: 1/10 (1)
Посмотреть все анекдоты