[ <<<
| 1
| 2
| 3
| 4
| 5
| 6
| >>>
]
Как и почему преуспевают объектно-ориентированные методы
Теперь, когда мы исследовали нисходящее подход, и нашли его желательным в некоторых областях, можно направить наше внимание к объектно-ориентированному проектированию и увидеть, действительно ли оно решает любую из проблем, которые мы обнаружили.
Обзор объектно-ориентированного анализа и проектирования
Объектно-ориентированный анализ начинается с исследования предметов реального мира, являющихся частью решаемой задачи. Эти предметы, которые мы назовем объектами, индивидуально характеризуются атрибутами состояния (информацией, хранимой в переменных) и поведения (операторами обработки информации). Используя объектно-ориентированную терминологию, мы формируем и описываем классы, охватывающие проблемную область. Одновременно с описанием этих индивидуальных характеристик мы также моделируем связи или взаимодействие между объектами предметной области (и, следовательно, классы, обеспечивающие наше решение). Эти связи могут устанавливаться в форме агрегирования частей (это - часть того), делегирования (это использует то) или наследование (это - то).
Затем объектно-ориентированное проектирование переходит от моделирования предметной области к моделированию области реализации. Структура нашего класса теперь начинает включать описания специфических компьютерных объектов. Например: классы интерфейса пользователя (окна, меню, и т.д.), классы управления задачами (процессы, семафоры, и т.д.), классы обработки данных (списки, стеки, очереди, и т.д.). Поскольку объектно-ориентированный анализ и проектирование используют тот же самый язык (и могут использовать те же самые системы обозначений), проще (и более выгодно) выполнять оба процесса параллельно и итерационно. Как указывает Гради Буч (Grady Booch):
"Границы между анализом и проектированием размыты, хотя фокус каждого полностью различен. При анализе, мы пытаемся моделировать мир, обнаруживая классы и предметы, которые формируют словарь предметной области, а при проектировании, мы изобретаем абстракции и механизмы, которые обеспечивают поведение, требуемой этой моделью."
Чрезвычайно важно отметить, что цели процессов анализа и процесса проектирования не сосредоточены исключительно на разработке решения, необходимого для текущего понимания проблемы. Скорее, они направлены на проектирование и формирование обобщенных классов с законченными и полезными структурами. Модели класса изложены в деталях и завершены вне частных текущих потребностей. Используя жаргон Мейера, можно сказать, что мы хотим, чтобы наши классы имели завершенный товарный список атрибутов и поведения.
- Пример 1. Если решение требует стек целых чисел, объектно-ориентированный подход реализовал бы идею, что стеки - интересные и полезные объекты сами по себе и, следовательно, могут быть смоделированы независимо от частных потребностей целых чисел
.
Пример 2. Если бы решение требовало отслеживания небольшого списка телефонных номеров, мы бы не моделировали класс списка телефонных номеров. Взамен, мы моделировали бы общий класс списка, а затем смоделировали бы список телефонных номеров, использующий список (путем делегирования или наследования). Этот класс имел бы все функциональные возможности, которые имеют списки (добавление элементов, удаление элементов, поиск элемента, сортировка списка, и т.д.). Заметьте, что мы можем проектировать наш класс без того, чтобы волноваться относительно остальной части предметной области. Эта способность рассматривать классы абстрактно и (частично) изолированно - одна из особенностей объектно-ориентированной методологии. Мы можем концентрировать наше внимание на малом даже при решении больших и комплексных задач.
Преимуществом этого, более общего, подхода, является то, что наши классы будут иметь возможности многократного использования в новых ситуациях, более расширяемыми и более совместимыми друг с другом. Они будут многократно используемыми, потому что разработаны не для одиночной задачи, а для моделирования конкретных характеристик объектов реального (или компьютерного) мира. Так как вполне вероятно, что тот же самый "предмет" вновь появится в других задачах, наша законченная модель, будет использована там, даже если предмет реализуется совершенно другим способом. Они будут расширяемы, потому что они разработаны обобщенно, без привязки к особенностям одной задачи. Могут быть добавлены дополнительные функциональные возможности, изменена реализация без того, чтобы нанести вред фундаментальным абстракциям. Классы будут более совместимы, потому что они разработаны так, чтобы быть завершенными, иметь ясно определенные (и защищенные) интерфейсы. Это означает, что они будут способны существовать в новых ситуациях без изменения.
Мы получили то, что позволяет нашим моделям не быть разбитыми и потерпевшими неудачу при изменении текущих требований. Дополнительным эффектом является то, что они будут полезны для решений многих других задач. При продолжительном использовании объектно-ориентированных методов, мы обнаружим, что имеем сундук с сокровищами в виде многократно используемых классов, применимых к различным проблемам, которые нам надо решить.
Объектно-ориентированное проектирование. Резюме
Мейер дает следующее формальное определение объектно-ориентированное проектирования: "конструирование программных систем в виде структурированных коллекций, реализующих абстрактные типы данных". Неформально он определяет это как "метод, который ведет к архитектурам программ, основанным на объектах, используемых системой или подсистемой (предпочтительнее чем "функция", которую система, как предполагается, выполняет)". Объект может быть рассмотрен как реализация некоторых знаний и некоторые операций, концептуально связанных друг с другом, так, чтобы имело смысл связывать их вместе.
Построить систему с применением объектно-ориентированного подхода - это значит, что надо проанализировать проблему и найти объекты, охватываемые системой. Общие характеристики, черты и поведение этих объектов затем моделируются и реализуются как классы в объектно-ориентированном языке программирования. Смоделированные однажды объекты предметной области, реализованные как классы (или полученные из предыдущих проектов, или библиотеки классов третьих лиц), затем собираются вместе, чтобы моделировать систему внутри компьютерного каркаса. Этот восходящий подход, опирающийся на прошлые усилия, позволяет создавать заказные системы, сформированные из готовых частей.
[ <<<
| 1
| 2
| 3
| 4
| 5
| 6
| >>>
]
|