Объектно-ориентированный дизайн

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

Обзор

Объект данные и процедуры , содержит инкапсулированные сгруппированные для представления сущности. «Интерфейс объекта» определяет, как с объектом можно взаимодействовать. Объектно-ориентированная программа описывается взаимодействием этих объектов. Объектно-ориентированное проектирование — это дисциплина определения объектов и их взаимодействий для решения проблемы, которая была выявлена ​​и задокументирована в ходе объектно-ориентированного анализа .

Далее следует описание подмножества объектно-ориентированного проектирования на основе классов , которое не включает подходы , основанные на прототипах объектов , где объекты обычно получаются не путем создания экземпляров классов, а путем клонирования других (прототипов) объектов. Объектно-ориентированное проектирование — это метод проектирования, включающий в себя процесс объектно-ориентированной декомпозиции и обозначение для изображения как логических и физических, так и состояний и динамических моделей проектируемой системы.

Темы объектно-ориентированного проектирования

Входные данные (исходники) для объектно-ориентированного проектирования

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

Вот некоторые типичные входные артефакты объектно-ориентированного проектирования:

• Концептуальная модель : результат объектно-ориентированного анализа, фиксирующий концепции проблемной области . Концептуальная модель явно выбирается независимой от деталей реализации, таких как параллелизм или хранение данных.
• Вариант использования : описание последовательности событий, которые в совокупности приводят к тому, что система делает что-то полезное. Каждый вариант использования предоставляет один или несколько сценариев , которые описывают, как система должна взаимодействовать с пользователями, называемыми субъектами, для достижения определенной бизнес-цели или функции. Субъектами варианта использования могут быть конечные пользователи или другие системы. Во многих случаях варианты использования дополнительно детализируются в диаграммы вариантов использования . Диаграммы вариантов использования используются для идентификации действующих лиц (пользователей или других систем) и процессов, которые они выполняют.
• Диаграмма последовательности системы . Диаграмма последовательности системы (SSD) — это изображение, которое показывает для конкретного сценария варианта использования события, генерируемые внешними субъектами, их порядок и возможные межсистемные события.
• Документация пользовательского интерфейса (если применимо): документ, который показывает и описывает внешний вид пользовательского интерфейса конечного продукта. Это не обязательно, но это помогает визуализировать конечный продукт и, следовательно, помогает дизайнеру.
• Реляционная модель данных (если применимо). Модель данных — это абстрактная модель, которая описывает, как данные представляются и используются. Если объектная база данных не используется, реляционную модель данных обычно следует создавать до проектирования, поскольку стратегия, выбранная для объектно-реляционного сопоставления, является результатом процесса объектно-ориентированного проектирования. Однако можно разрабатывать реляционную модель данных и артефакты объектно-ориентированного проектирования параллельно, а рост одного артефакта может стимулировать совершенствование других артефактов.

Объектно-ориентированные концепции

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

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

Концепции проектирования

• Определение объектов, создание диаграммы классов на основе концептуальной диаграммы : обычно сопоставляет сущность с классом.
• Определение атрибутов и их моделей.
• Используйте шаблоны проектирования (если применимо). Шаблон проектирования — это не законченный проект, а описание решения распространенной проблемы в контексте.

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

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

Результаты (результаты) объектно-ориентированного проектирования

• Диаграмма последовательности . Расширьте диаграмму последовательности системы , добавив определенные объекты, которые обрабатывают системные события.

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

• Диаграмма классов . Диаграмма классов — это тип UML- диаграммы статической структуры, которая описывает структуру системы, показывая классы системы, ее атрибуты и отношения между классами. Сообщения и классы, определенные при разработке диаграмм последовательности, могут служить входными данными для автоматического создания глобальной диаграммы классов системы.

принципы и

• Внедрение зависимостей . Основная идея заключается в том, что если объект зависит от наличия экземпляра какого-либо другого объекта, то необходимый объект «вводится» в зависимый объект; например, подключение к базе данных передается в качестве аргумента конструктору вместо его внутреннего создания.
• Принцип ациклических зависимостей : Граф зависимостей пакетов или компонентов (детализация зависит от объёма работ одного разработчика) не должен иметь циклов. Это также называется ориентированным ациклическим графом . Например, пакет C зависит от пакета B, который зависит от пакета A. Если бы пакет A зависел от пакета C, у вас был бы цикл.
• Принцип составного повторного использования : отдавайте предпочтение полиморфной композиции объектов, а не наследованию.

См. также

• Карточка классовой ответственности и сотрудничества
• GRASP (объектно-ориентированное проектирование)
• ТВЕРДЫЙ
• IDEF4
• Объектно-ориентированный анализ
• Объектно-ориентированное программирование

Внешние ссылки

• Объектно-ориентированный анализ и проектирование — обзор использования UML
• Ларман, Крейг. Применение UML и шаблонов — третье издание
• Объектно-ориентированный анализ и проектирование
• LePUS3 и Class-Z : формальные языки моделирования для объектно-ориентированного проектирования.