Готовый перевод Non-Programmer's Tutorial for Python / Человеческий учебник по языке программирования Python: Hello, World

Обзор

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

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

Далее приводится описание классификации в объектно-ориентированном проектировании, куда не входят объектно- прототипные подходы, поскольку в них объекты обычно получены не путём определения принадлежности к классу, а путём клонирования других (прототипных) объектов.

Вопросы объектно-ориентированного дизайна

Вводные данные (источники) в объектно-ориентированном проектировании (дизайне)

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

Некоторые типовые вводимые артефакты в объектно-ориентированном проектировании:

*Концептуальная модель. Концептуальная модель - это результат объектно-ориентированного анализа, она выбирает концепции из области задач. Концептуальная модель специально предназначена быть независимой от деталей реализации, таких как совпадение или хранение данных.

* Диаграммы использования (прецедентов): Диаграммы использования описывают последовательность действий, направленных на получение некоего полезного результата от системы. Каждое действие (прецедент, use case) описывает один или несколько сценариев взаимодействия пользователя (актёра, актора) для достижения им его цели. Актёром может быть конечный пользователь системы. Во многих случаях простое описание сценариев приводит к созданию диаграммы использования. Диаграммы использования служат для идентификации актёров (пользователей или других систем) и процессов, которые они выполняют.

Диаграмма последовательностей системы (System Sequence Diagram) является схемой, которая для определенного сценария прецедента показывает генерируемые внешними исполнителями события, их порядок, а также возможные события, генерируемые внутри самой системы.

* Документация по пользовательскому интерфейсу (если необходимо): Документ, который описывает взгляды и пожелания по поводу интерфейса конечного продукта. Это, конечно, необязательно иметь такой документ, однако, он позволит представить конечный продукт и, может быть, поможет проектировщикам.

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

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

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

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

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

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

* Определение объектов, создание диаграммы классов из концептуальных диаграмм: Как правило, сущности списка (map) в класс.

* Определение атрибутов.

* Использование шаблонов проектирования (если применимо): Шаблон проектирования (design pattern) не законченный проект, это описание решения общей проблемы, в контексте [1]. Главным преимуществом использования шаблонов проектирования является то, что каждый шаблон может быть повторно использован в различных приложениях. Он также может рассматриваться в качестве типичного шаблона для решения проблем, который может быть использован в различных ситуациях и/или прриложениях. Шаблоны объектно-ориентированного проектирования, как правило, отражают отношения и взаимодействия между классами и объектам, без спецификации классов законченного приложения или вовлеченных объектов.

* Определение фреймворка приложения (application framework) (если применимо): Термин фреймворк, обычно используется для обозначения набора библиотек или классов, которые используются для реализации стандратной структуры приложения для конкретной операционной системы. Объединенение большого количества повторно используемого кода в своеобразную базу, значительно экономит время разработчика, так как он/она освобождается от необходимости переписывать большое количество стандартного кода для каждого нового разрабатываемого приложения.

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

* Идентифицировать и определить удаленные объекты (если необходимо)

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

* Диаграмма последовательностей: Расширенная диаграмма последовательностей системы (System Sequence Diagram), включающая в себя специальные объекты, являющиеся обработчиками системных событий.

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

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

Некоторые принципы и стратегии проектирования

* Зависимость инъекций: Основная идея состоит в том, что если объект зависит от существующего экземпляра другого объекта, то необходимый объект "вводится" (injected) в зависимый объект, например, соединение с базой данных передается в качестве аргумента в конструктор, вместо создания еще одного внутри.
* Принцип ациклическиой зависимости: граф зависимостей пакетов или компонентов не должен иметь никаких циклов. Также это называется направленным ациклическим графом. [2] Например, пакет С зависит от пакета B, который зависит от пакета A. Если пакет A также зависит от пакета C, то вы получаете цикл.
* Композитный принцип повторного использования. Полезная полиморфная композиция объектов по наследству. [1]
(* Composite reuse principle: Favor polymorphic composition of objects over inheritance.)

Переведено на Нотабеноиде
http://notabenoid.org/book/2776/8947

Переводчики: boxesofmatches, victor8632, Lisok, kostikvento

RedFox, Albedo