Парадигма ооп: Что такое ООП?

Объектно-ориентированная парадигма — CoderLessons.com

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

• Первым объектно-ориентированным языком был Simula (Симуляция реальных систем), который был разработан в 1960 году исследователями из Норвежского вычислительного центра.

• В 1970 году Алан Кей и его исследовательская группа в Xerox PARC создали персональный компьютер по имени Dynabook и первый чистый объектно-ориентированный язык программирования (OOPL) — Smalltalk, для программирования Dynabook.

• В 1980-х Грэди Буч опубликовал статью под названием «Объектно-ориентированный дизайн», в которой в основном представлен дизайн для языка программирования Ada. В последующих изданиях он расширил свои идеи до полного метода объектно-ориентированного проектирования.

• В 1990-х годах Коад включил идеи поведения в объектно-ориентированные методы.

Первым объектно-ориентированным языком был Simula (Симуляция реальных систем), который был разработан в 1960 году исследователями из Норвежского вычислительного центра.

В 1970 году Алан Кей и его исследовательская группа в Xerox PARC создали персональный компьютер по имени Dynabook и первый чистый объектно-ориентированный язык программирования (OOPL) — Smalltalk, для программирования Dynabook.

В 1980-х Грэди Буч опубликовал статью под названием «Объектно-ориентированный дизайн», в которой в основном представлен дизайн для языка программирования Ada. В последующих изданиях он расширил свои идеи до полного метода объектно-ориентированного проектирования.

В 1990-х годах Коад включил идеи поведения в объектно-ориентированные методы.

Другими значительными нововведениями стали «Методы объектного моделирования» (OMT) Джеймса Рам Боуг и «Объектно-ориентированная программная инженерия» (OOSE) Ивара Якобсона .

Введение в OO Paradigm

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

Основные понятия и терминология объектно-ориентированных систем —

объект

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

• Идентичность, которая отличает его от других объектов в системе.

• Состояние, определяющее характерные свойства объекта, а также значения свойств, которые он содержит.

• Поведение, которое представляет внешне видимые действия, выполняемые объектом с точки зрения изменений в его состоянии.

Идентичность, которая отличает его от других объектов в системе.

Состояние, определяющее характерные свойства объекта, а также значения свойств, которые он содержит.

Поведение, которое представляет внешне видимые действия, выполняемые объектом с точки зрения изменений в его состоянии.

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

Учебный класс

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

Составляющие класса —

• Набор атрибутов для объектов, которые должны быть созданы из класса. Как правило, разные объекты класса имеют некоторые различия в значениях атрибутов. Атрибуты часто называют данными класса.

• Набор операций, которые отображают поведение объектов класса. Операции также называются функциями или методами.

Набор атрибутов для объектов, которые должны быть созданы из класса. Как правило, разные объекты класса имеют некоторые различия в значениях атрибутов. Атрибуты часто называют данными класса.

Набор операций, которые отображают поведение объектов класса. Операции также называются функциями или методами.

пример

Рассмотрим простой класс Circle, представляющий круг геометрической фигуры в двумерном пространстве. Атрибуты этого класса могут быть определены следующим образом:

• х – координата, для обозначения х – координаты центра
• у – координата, для обозначения у – координата центра
• а, чтобы обозначить радиус круга

Некоторые из его операций могут быть определены следующим образом:

• findArea (), метод для расчета площади
• findCircumference (), метод для вычисления окружности
• scale (), метод увеличения или уменьшения радиуса

Инкапсуляция

Инкапсуляция — это процесс связывания атрибутов и методов вместе в классе. Благодаря инкапсуляции внутренние детали класса могут быть скрыты снаружи. Он разрешает доступ к элементам класса извне только через интерфейс, предоставляемый классом.

Полиморфизм

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

пример

Давайте рассмотрим два класса, Circle и Square, каждый из которых имеет метод findArea (). Хотя имя и назначение методов в классах одинаковы, внутренняя реализация, т. Е. Процедура вычисления площади, различна для каждого класса. Когда объект класса Circle вызывает свой метод findArea (), операция находит область круга без какого-либо конфликта с методом findArea () класса Square.

Отношения

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

Передача сообщений

Любое приложение требует, чтобы несколько объектов взаимодействовали гармонично. Объекты в системе могут взаимодействовать друг с другом с помощью передачи сообщений. Предположим, что система имеет два объекта — obj1 и obj2. Объект obj1 отправляет сообщение объекту obj2, если obj1 хочет, чтобы obj2 выполнил один из своих методов.

Состав или Агрегация

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

ассоциация

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

• Унарные отношения связывают объекты одного класса.
• Бинарные отношения связывают объекты двух классов.
• Тройные отношения связывают объекты трех или более классов.

наследование

Это механизм, который позволяет создавать новые классы из существующих классов, расширяя и совершенствуя его возможности. Существующие классы называются базовыми классами / родительскими классами / суперклассами, а новые классы называются производными классами / дочерними классами / подклассами.

Подкласс может наследовать или получать атрибуты и методы суперкласса (ов) при условии, что суперкласс позволяет это. Кроме того, подкласс может добавлять свои собственные атрибуты и методы и может модифицировать любой из методов суперкласса. Наследование определяет отношения «есть -».

пример

Из класса млекопитающих может быть получен ряд классов, таких как человек, кошка, собака, корова и т. Д. Люди, кошки, собаки и коровы имеют отличительные характеристики млекопитающих. Кроме того, у каждого есть свои особенности. Можно сказать, что корова — это млекопитающее.

ОО Анализ

На этапе объектно-ориентированного анализа разработки программного обеспечения определяются системные требования, определяются классы и признаются взаимосвязи между классами. Целью анализа ОО является понимание области применения и конкретных требований системы. Результатом этого этапа является определение требований и первоначальный анализ логической структуры и выполнимости системы.

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

Моделирование объектов

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

Процесс моделирования объекта может быть визуализирован в следующих шагах —

• Определить объекты и сгруппировать в классы
• Определите отношения между классами
• Создать диаграмму модели объекта пользователя
• Определите атрибуты объекта пользователя
• Определите операции, которые должны быть выполнены на классах

Динамическое Моделирование

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

Динамическое моделирование может быть определено как «способ описания того, как отдельный объект реагирует на события, либо внутренние события, инициируемые другими объектами, либо внешние события, инициируемые внешним миром».

Процесс динамического моделирования может быть визуализирован в следующих шагах —

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

Функциональное моделирование

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

Процесс функционального моделирования может быть визуализирован в следующих шагах —

• Определите все входы и выходы
• Построить диаграммы потоков данных, показывающие функциональные зависимости
• Укажите цель каждой функции
• Определить ограничения
• Укажите критерии оптимизации

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

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

Этапы объектно-ориентированного проектирования могут быть определены как —

• Определение контекста системы
• Проектирование архитектуры системы
• Идентификация объектов в системе
• Построение дизайнерских макетов
• Спецификация объектных интерфейсов

ОО Дизайн можно разделить на два этапа — Концептуальный дизайн и Детальный дизайн.

Концептуальный дизайн

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

Детальный дизайн

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

Принципы дизайна

Ниже приведены основные принципы дизайна —

Принцип развязки

Сложно поддерживать систему с набором сильно взаимозависимых классов, поскольку изменение одного класса может привести к каскадным обновлениям других классов. В ОО-дизайне тесная связь может быть устранена путем введения новых классов или наследования.

Обеспечение сплоченности

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

Открыто-закрытый принцип

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

Для каждого конкретного класса должен поддерживаться отдельный интерфейс и реализации.

В многопоточной среде сохраняйте атрибуты закрытыми.

Минимизируйте использование глобальных переменных и переменных класса.

Три парадигмы / Хабр

Привет, Хабр!

Предлагаю вашему вниманию перевод статьи «Three Paradigms» автора Robert C. Martin (Uncle Bob).

За последние 40 лет технологии аппаратного обеспечения увеличили вычислительную мощность наших устройств более чем на двадцать порядков. Теперь мы играем в Angry Birds на наших телефонах, которые обладают вычислительной мощностью суперкомпьютера 70-х годов прошлого века с фреоновым охлаждением.

Но за те же 40 лет технологии программного обеспечения практически не изменились. В конце концов, мы все так же применяем операторы if, while loops и операторы присваивания, которые мы использовали еще в 60-х годах. Если бы я взял программиста из 1960 года и привел его сюда, чтобы он посидел за моим ноутбуком и написал код — ему понадобилось бы 24 часа, чтобы оправиться от шока, но он смог бы написать этот код. Принципы не так сильно изменились.

В процессе написания программ изменились три вещи. Я говорю не об оборудовании, не о скорости компьютера и не о невероятных инструментах, которые у нас есть. Я имею в виду сам код. Три вещи изменились в коде. Можно их назвать парадигмами. И все они были «открыты» за одно десятилетие более 40 лет назад.

* 1968 — Структурное программирование. Эдсгер Дейкстра написал свою статью: «О вреде оператора Go To» и ряд других документов и статей, в которых предлагается отказаться от использования необузданного подхода Go To, заменив его такими средствами, как if/then/else и while loops.

* 1966 — Объектно-ориентированное программирование. Оле-Йохан Даль и Кристен Нюгор, изучая язык Алгол, «Открывают» объекты и создают первый объектно-ориентированный язык-Симула-67. Несмотря на то, что это достижение имеет множество перспектив, оно не принесло никаких новых возможностей в наш код. Кроме того, оно удалило одну. Ведь с появлением полиморфизма необходимость в указателях на функции отпала, а на самом деле исчезла.

* 1957 — Функциональное программирование. Джон Маккарти создает Lisp-первый функциональный язык. Lisp был основан на лямбда-исчислении, созданном Алонзо Чёрчем в 30-х годах. Хотя существует много перспектив функционального программирования, однако во всех функциональных программах существует одно огромное ограничение. Они не используют присваивание.

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

Можем ли мы создать другую парадигму? Есть что-нибудь еще, что можно убрать?

За 40 лет не было новой парадигмы, так что, возможно, это хороший признак того, что больше нечего искать.

Должны ли мы использовать все эти парадигмы, или мы можем выбирать?

Со временем мы решили внедрить их. Внедрение первого структурированного программирования стало возможным благодаря отмене принципа Go To (как рекомендовал Дейкстра в своей статье). ООП была успешно внедрена путем замены указателей функциями в наших современных языках с помощью полиморфизма (например, Java, C#, Ruby). Поэтому, по крайней мере, для этих двух, ответом на данный вопрос является то, что мы ОБЯЗАНЫ использовать их. Все другие варианты были исключены или, по крайней мере, строго ограничены.

А как же функциональное программирование? Должны ли мы использовать языки, не имеющие оператора присваивания? Наверное, да! Мы уже занимаемся написанием кода, который должен хорошо работать на нескольких ядрах, и эти ядра размножаются, как кролики. Мой ноутбук имеет 4 ядра. У моего следующего, скорее всего, будет 8. Тот, что после 16. Как вы собираетесь писать надежный код с 4096 процессорами, борющимися за право доступа к шине?

Мы едва ли сможем заставить работать два параллельных потока, не говоря уже о 2^n процессорах.

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

Подробнее о функциональном программировании мы поговорим в последующих блогах. Что меня поражает в трех парадигмах, упомянутых выше, так это их даты. Они древние, почти старше меня. И с тех пор, как мне исполнилось 16, 42 года назад, новых не было.

Парадигмы программирования — парадигмы жизни / Песочница / Хабр

Введение

В данной статье я постараюсь поверхностно, не углубляясь в дебри, раскрыть понятие “Парадигма программирования”. Стоит отметить, что статья написана простым языком, в ней практически не рассматриваются сложные термины и специфичные для языков программирования понятия, поэтому она подойдет для прочтения как опытным программистам, так и людям, которые никогда не писали код.

Парадигма программирования

Ну что же, приступим. Скорее всего, многим данное словосочетание покажется пугающим, но, на самом же деле, здесь нет ничего сложного. Что же такое “Парадигма программирования”? Возьмем определение из википедии: “Парадигма программирования – это совокупность идей и понятий, определяющих стиль написания компьютерных программ (подход к программированию). Это способ концептуализации, определяющий организацию вычислений и структурирование работы, выполняемой компьютером”.

— Хмм, непонятно!

Если говорить самым простым языком, то парадигма программирования – это подход к написанию кода. Читатели без опыта программирования, вероятнее всего, зададутся вопросами: “А что это за такие подходы? То есть, например, ты пишешь код сначала левой рукой, потом правой? Или же ты пишешь код час, а потом полчаса отдыхаешь? Что это за подходы?!”. На самом же деле, подходы подразумевают под собой совсем другое и далеки от примеров, описанных до этого.

Чтобы понять, что это такое, давайте рассмотрим два основных подхода, то есть две основные парадигмы: Объектно-ориентированное программирование (ООП) и Функциональное программирование (ФП). ООП основано на том, что все можно представить в виде объектов, у которых могут быть какие-то характеристики (поля) и они могут выполнять какие-то действия (методы/функции). ФП же основано на описание процессов (функций), а не объектов. Понимаю, пока не понятно, поэтому давайте разберем простейший пример. Представим, что нам нужно как-то складывать и вычитать два числа (a и b). На картинке ниже представлен код, реализующий это в ООП и ФП (код был специально упрощен, чтобы сделать упор именно на разнице двух подходов). Вы сразу можете заметить функции “sum” (сложение) и “subtract” (вычитание), которые мы хотели реализовать.

— Так, ну функции я вижу, а почему в ООП есть еще “class Calculator”, что это значит?

Как уже было сказано выше, ООП основано на том, что все можно представить в виде объектов: например, есть объект “Вселенная”, она состоит из галактик (объект “Галактика”), та, в свою очередь, состоит из планет (объект “Планета”), на каждой планете могут быть люди (объект “Человек”) и так далее. Возьмем, например, объект “Человек”, его характеристиками (полями) могут быть: цвет кожи, пол, рост, возраст (что-то еще). И также он может выполнять следующие действия (методы/функции): бегать, кушать, работать и так далее. Вы легко можете спроецировать такой подход (парадигму) на жизнь, представить все вокруг с помощью объектов и вы поймете, что любое действие (метод/функция) связано с каким-либо объектом, оно не может существовать само по себе, кто-то должен его выполнять. Именно по этой причине наши действия (методы/функции) “sum” и “subtract” находятся внутри объекта “Calculator” (Калькулятор).

— Интересно! Про ООП я понял, а почему в ФП все функции ни к чему не привязаны, находятся сами по себе?

Помните я говорил, что ФП основано на процессах (функциях)? Давайте опять попробуем спроецировать это на нашу жизнь. Например, возьмем процесс (функцию) создания вселенной, галактики, планеты, человека, процесс (функцию) сложения, вычитания и т.д. Сам процесс (функция) никому не принадлежит — он общий, пользоваться может кто угодно, но при этом каждый процесс (функция) имеет определенные условия, в зависимости от которых получается тот или иной результат. Рассмотрим простой пример из жизни, процесс “Приготовление ужина”: данный процесс может осуществить кто угодно, даже ваш кот или собака, но так как опыта у них нет, то, вероятнее всего, ужин просто не будет приготовлен. То есть получается, что воспользоваться могут все, но результат будет разный.

— Фух, ну теперь понятно, что такое парадигма программирования. Ну все-таки остался вопрос: почему где-то используется одна парадигма, а где-то другая?

Вы удивитесь, но на самом деле, две эти парадигмы можно использовать одновременно. Опять-таки, давайте рассмотрим простой пример, спроецированный на реальную жизнь. Представим, что у нас есть:

1. [ООП] Объект “Человек”, который не имеет никаких характеристик (полей) (например, пол, рост и количество лет), но зато умеет готовить (имеет действие (метод/функцию) “приготовить ужин”)
2. [ООП] Объект “Собака”, у которой есть такие характеристики (поля), как цвет шерсти, возраст. И также она умеет бегать (имеет действие (метод/функцию) “бежать”)
3. [ФП] Процесс (функция) “Приготовление ужина”.

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

Заключение

Итак, в этой статье мы можно сказать на пальцах, без специфических терминов, разобрали основные различия парадигм ООП и ФП. К сожалению, тут нам пора остановиться. Теперь ваш ход – самостоятельно углублять знания с помощью дополнительной литературы.

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

Используемая литература

Существуют только структурная и объектная парадигмы программирования / Хабр

Эту статью я подготовил во время дискуссий по поводу паттерна Мост, но тогда не опубликовал. Думал разобрались, так как было упомянута Domain Driven Design, и казалось, что необходимость проектирования и программирования именно в стиле ООП никем не оспариваются. Но все же со временем я столкнулся с непониманием. Это будет чисто историческая теоретическая статья. Конечно, даже без попытки обхвата всей широты темы. Но это так сказать посыл молодому разработчику, который читает по верхам и не может выбрать каких принципов и правил ему придерживаться, что первично, а что вторично.

Заглавие этой темы для многих сейчас может показать очень спорным (и скорее намерено провокационным, но для дела 🙂 ). Но все же мы постараемся это здесь обосновать и понять какими свойствами должна обладать парадигма программирования, чтобы иметь право называться парадигмой.

Единственно прошу, если прочитали по диагонали — комментируйте сдержано.

Что нам говорит Флойд о парадигмах?

Термин «парадигма программирования» ввел Роберт Флойд (»R. W. Floyd.» [http://www.ias.ac.in/resonance/May2005/pdf/May2005Classics.pdf The Paradigms of Programming] »Communications of the ACM», 22(8):455—460, 1979. Русский перевод см. в кн.: Лекции лауреатов премии Тьюринга за первые двадцать лет (1966—1985), М.: МИР, 1993.). Он в своей лекции в 1979 году говорит о следующем:

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

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

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

Особенности парадигм более высокого уровня

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

Как мы видим Р. Флойд тоже различал парадигмы на более высокоуровневые, и более специализированные. Какие же особенности парадигм позволяют говорить, что они более высокоуровневые? Конечно, это возможность их применения к различным предметным задачам. Но что делает парадигмы, применимым к различным предметным задачам? Конечно, вопрос тут не в особенностях предметной задачи, которую можно решить тем или иным подходом. Все парадигмы, которые предлагают создавать алгоритмы тем или иным специализированным способом — вовсе не являются парадигмами, это лишь особый подход в рамках парадигмы более высокого уровня.

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

Но возвратимся к нашему вопросу: что делает парадигмы, применимым к различным предметным задачам? Но чтобы на него ответить нам нужно сделать исторический экскурс.

Основы парадигмы структурного программирования

Мы знаем, что идеи о структурном программировании возникли после доклада Э. Дейкстры еще в 1965 году, где он обосновал отказ от оператора GOTO. Именно этот оператор превращал программы в неструктурированные (Спагетти-код), а Дейкстра доказал, что возможно написать программы без использования этого оператора в результате чего программы станут структурными.

Но одно дело теория, а другое практика. В этом смысле, представляет интерес рассмотреть, какая ситуация была к 1975 году. Это хорошо видно по книге Э. Йодана ([http://www.az-design.ru/index.shtml?Projects&AzBook&src/005/02YE000 Йодан Э. Структурное проектирование и конструирование программ, 1975]). Рассмотреть это важно потому, что сейчас спустя более 30 лет, принципы уже хорошо известные тогда, сейчас переоткрываются, и возводятся в новый ранг. Но при этом теряется исторический контекст, и иерархия важности этих принципов, что первично, а что вторично. Эта ситуация аморфности очень хорошо характеризует сегодняшнее состояние программирования.

Но что было тогда? Как описывает Йодан, все начинается с ответа на вопрос: «Что значит написать хорошую программу?». Вот первый критерий, на какие вопросы должна отвечать парадигма программирования высокого уровня. Если она не отвечает прямо на этот вопрос, а рассказывает вам как можно получить некоторые интересные характеристики вашей программы, то вы имеете дело с парадигмой низкого уровня — подходом при программировании.

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

Примечателен, довольно характерный спор программистов:

* Программист А: “Моя программа в десять раз быстрее вашей, и она занимает в три раза меньше памяти!”

* Программист Б: “Да, но ваша программа не работает, а моя — работает!”

Но программы постоянно усложняются и поэтому нам недостаточно того, что программа просто работает. Нужны определенные методы верификации правильности работы программы и самого программиста. Причем это не тестирование программы, а проведение некоторой систематической процедуры проверки именно правильности программы в смысле её внутренней организации. То есть уже тогда, говоря современным языком, говорили о ревизии кода (Code review).

Кроме того, уже тогда говорили о гибкости программы — о простоте ее изменения, расширения и модификации. Для этого необходимо постоянно отвечать на вопросы определенного вида. “Что будет, если мы захотим расширить эту таблицу?”, “Что произойдет, если однажды мы захотим определить новую программу изменений?”, “А что, если нам придется изменить формат таких-то выходных данных?”, “Что будет, если кто-то решит вводить данные в программу другим способом?”.

Также говорили о важности спецификаций интерфейсов, т.е. формализованный подход к спецификации входов, функций и выходов, которые должны быть реализованы каждым модулем.

Кроме того, центральное внимание уделяли размеру и неизменности модуля. Причем что касается неизменности модуля, то она рассматривалась не целиком, а с выделением отдельных факторов:

1. Логическая структура программы, т.е. алгоритм. Если вся программа зависит от некоторого специального подхода, то в скольких модулях потребуется внести изменения при изменении алгоритма?

2. Аргументы, или параметры, модуля. Т.е. изменение спецификации интерфейсов.

3. Внутренние переменные таблиц и константы. Многие модули зависят от общих таблиц, если изменяется структура таких таблиц, то мы можем ожидать, что модули также изменятся.

4. Структура и формат базы данных. В большей степени эта зависимость аналогична зависимости от общих переменных и таблиц, упомянутой выше, с той разницей, что с практической точки зрения базу данных удобнее считать независимой от программы.

5. Модульная структура управления программой. Некоторые пишут модуль не особенно задумываясь над тем, каким образом он будет использоваться. Но если изменились требования. Какую часть логической структуры модуля нам придется изменить?

Эти и множество других аспектов (которые мы тут не рассмотрели) в целом и формулируют представление о структурном программировании. Забота об этих аспектах и делает структурное программирование парадигмой высокого уровня.

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

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

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

Уже признано, что причиной появления объектно-ориентированной парадигмы стала необходимость писать все более и более сложные программы, в то время как парадигма структурного программирования имеет некий предел, после которого развивать программу становится невыносимо сложно. Вот, например, что пишет Г. Шилдт:

На каждом этапе развития программирования появлялись методы и инструментальные средства для “обуздания” растущей сложности программ. И на каждом таком этапе новый подход вбирал в себя все самое лучшее из предыдущих, знаменуя собой прогресс в программировании. Это же можно сказать и об ООП. До ООП многие проекты достигали (а иногда и превышали) предел, за которым структурный подход к программированию оказывался уже неработоспособным. Поэтому для преодоления трудностей, связанных с усложнением программ, и возникла потребность в ООП. ([http://www.williamspublishing.com/Books/978-5-8459-1684-6.html Герберт Шилдт, C# 4.0 полное руководство, 2011])

Чтобы понять причину, почему именно объектно-ориентированное программирование, позволило писать более сложные программы и практически убрать проблему возникновения предела сложности, обратимся к одному из основоположников ООП — Гради Бучу ([http://www.helloworld.ru/texts/comp/other/oop/index.htm Гради Буч, Объектно-ориентированный анализ и проектирование]). Свое объяснение ООП он начинает с того, что значит сложность и какие системы можно считать сложными. То есть целенаправленно подходит к вопросу написания сложных программ. Далее переходит к вопросу связи сложности и человеческих возможностей понять эту сложность:

Существует еще одна главная проблема: физическая ограниченность возможностей человека при работе со сложными системами. Когда мы начинаем анализировать сложную программную систему, в ней обнаруживается много составных частей, которые взаимодействуют друг с другом различными способами, причем ни сами части системы, ни способы их взаимодействия не обнаруживают никакого сходства. Это пример неорганизованной сложности. Когда мы начинаем организовывать систему в процессе ее проектирования, необходимо думать сразу о многом. К сожалению, один человек не может следить за всем этим одновременно. Эксперименты психологов, например Миллера, показывают, что максимальное количество структурных единиц информации, за которыми человеческий мозг может одновременно следить, приблизительно равно семи плюс-минус два. Таким образом, мы оказались перед серьезной дилеммой. »’Сложность программных систем возрастает, но способность нашего мозга справиться с этой сложностью ограничена. Как же нам выйти из создававшегося затруднительного положения?»’

Затем он говорит о декомпозиции:

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

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

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

Теперь, если посмотреть внимательнее, оказывается, что объектно-ориентированная парадигма есть не что иное как моделирование вообще, наиглавнейший аспект которого наиболее четко выразил С. Лем:

Моделирование — это подражание Природе, учитывающее немногие ее свойства. Почему только немногие? Из-за нашего неумения? Нет. Прежде всего потому, что мы должны защититься от избытка информации. Такой избыток, правда, может означать и ее недоступность. Художник пишет картины, но, хотя мы могли бы с ним поговорить, мы не узнаем, как он создает свои произведения. О том, что происходит в его мозгу, когда он пишет картину, ему самому неизвестно. Информация об этом находится в его голове, но нам она недоступна. Моделируя, следует упрощать: машина, которая может написать весьма скромную картину, рассказала бы нам о материальных, то есть мозговых, основах живописи больше, чем такая совершенная «модель» художника, какой является его брат-близнец. Практика моделирования предполагает учет некоторых переменных и отказ от других. Модель и оригинал были бы тождественны, если бы процессы, происходящие в них, совпадали. Этого не происходит. Результаты развития модели отличаются от действительного развития. На это различие могут влиять три фактора: упрощенность модели по сравнению с оригиналом, свойства модели, чуждые оригиналу, и, наконец, неопределенность самого оригинала. (фрагмент произведения «Сумма технологий», Станислав Лем, 1967)

Таким образом, С. Лем говорит о абстрагировании как основе моделирования. В тоже время абстрагирование и есть главный признак объектно-ориентированной парадигмы. Г. Буч по этому поводу пишет:

Разумная классификация, несомненно, — часть любой науки. Михальски и Степп утверждают: «неотъемлемой задачей науки является построение содержательной классификации наблюдаемых объектов или ситуаций. Такая классификация существенно облегчает понимание основной проблемы и дальнейшее развитие научной теории». Почему же классификация так сложна? Мы объясняем это отсутствием «совершенной» классификации, хотя, естественно, одни классификации лучше других. Кумбс, Раффья и Трал утверждают, что «существует столько способов деления мира на объектные системы, сколько ученых принимается за эту задачу». Любая классификация зависит от точки зрения субъекта. Флуд и Кэрсон приводят пример: «Соединенное Королевство… экономисты могут рассматривать как экономический институт, социологи — как общество, защитники окружающей среды — как гибнущий уголок природы, американские туристы — как достопримечательность, советские руководители — как военную угрозу, наконец, наиболее романтичные из нас, британцев — как зеленые луга родины».

И дальше он рассказывает, о выборе ключевых абстракций, тех которые нам необходимы:

»’Поиск и выбор ключевых абстракций.»’ Ключевая абстракция — это класс или объект, который входит в словарь проблемной области. »’Самая главная ценность ключевых абстракций заключена в том, что они определяют границы нашей проблемы»’: выделяют то, что входит в нашу систему и поэтому важно для нас, и устраняют лишнее. Задача выделения таких абстракций специфична для проблемной области. Как утверждает Голдберг, «правильный выбор объектов зависит от назначения приложения и степени детальности обрабатываемой информации».

Как мы уже отмечали, определение ключевых абстракций включает в себя два процесса: открытие и изобретение. Мы открываем абстракции, слушая специалистов по предметной области: если эксперт про нее говорит, то эта абстракция обычно действительно важна. Изобретая, мы создаем новые классы и объекты, не обязательно являющиеся частью предметной области, но полезные при проектировании или реализации системы. Например, пользователь банкомата говорит «счет, снять, положить»; эти термины — часть словаря предметной области. Разработчик системы использует их, но добавляет свои, такие, как база данных, диспетчер экрана, список, очередь и так далее. Эти ключевые абстракции созданы уже не предметной областью, а проектированием.

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

Итак, объектно-ориентированная парадигма становится парадигмой высокого уровня, и главенствует над принципами парадигмы структурного программирования, так как занимается моделированием реальности, строит модели предметных областей на языке специалистов этих областей. Если Вы этим пренебрежете ради написания хорошей программы, которую станет легко модифицировать, расширять, в которой будут четкие интерфейсы и независимые модули, вы возвратитесь на уровень парадигмы структурного программирования. Ваша программа будет всем хороша, но её нельзя будет понять, так как она не будет соответствовать реальности, она будет объяснена в терминах только известных вам, а специалист знающий предметную область не сможет без вашей помощи разобраться в программе. В конце концов, сложность будет понижаться в очень узком диапазоне, хотя вы и организовали хорошую программу. Но именно программу, а не модель. Отсутствие модели, или лишь её поверхностное представление, «взорвет» вашу хорошую программу изнутри, и не даст дальше развивать и сопровождать её в дальнейшем. Когда вы вводите классы, абстракций которых не существует, когда эти классы чисто системные и не имеют ничего общего с предметной областью, когда они введены лишь для упрощения потоков взаимодействия других классов — ваше программное обеспечение становится «с бородой», и если путем рефакторинга не следить за такими участками в один прекрасный момент развитие вашего ПО остановится, и станет не возможным — вы достигните предела структурного программирования (а вам казалось, используя классы и объекты вам это не грозит?).

upd. Я тут подумал, тема острая, я комментировать не буду. Факты я изложил в статье, а скатываться на уровень холивара не хочу. Если это не помогло задуматься — ну, что ж значит не повезло в этот раз. Действительно, будет конструктивно — если напишите контрдоводы в отдельной статье. Я же не берусь разрушать массовые стереотипы.

Да, и еще, чтобы было понятно — опубликовать я решил после дискуссий здесь Запрограммируем перцептрон Розенблатта?, где очевидным образом стало понятно, что функциональное программирование при построении плохой модели в ООП работает хуже не куда. И то, что они хвалятся супер скоростью — это фикция, на самом деле важна правильная модель. Для некоторых (не много таких задач сравнительно) функциональное программирование может быть успешным, но его не нужно использовать повсеместно, там где оно не дает ничего хорошего. Ну, или так — сможете написать обсуждаемый там кусок ТОЛЬКО в функциональном стиле, и чтобы это работало быстрее, чем с событиями ООП?

Десять вещей, которые я терпеть не могу в ООП / Хабр

Боже, временами я просто ненавижу объектно-ориентированное программирование.

Наверное, я не один такой. Бессмертные слова Эдсгера Дейкстры гласят:

«Объектно-ориентрованное программирование — это исключительно плохая идея, которую могли придумать только в Калифорнии.”

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

1. Парадигма

Что же есть парадигма объектно-ориентированного программирования? Есть ли на это прямой ответ? Я слышал столько разных версий, что и сам теперь не знаю.

Если мы посмотрим на идеи Smalltalk’а, мы столкнемся с мантрой: “Все есть объект”. Кроме переменных. И пакетов. И примитивов. Числа и классы тоже не совсем объекты, и так далее. Очевидно, “все есть объект” не может быть основой парадигмы.

Что для ООП является фундаментальным? Питер Вегнер однажды предположил, что основой объектно-ориентированного программирования являются объекты, классы и наследование. Однако, каждый язык программирования поддерживает их по-разному, или даже не поддерживает по умолчанию некоторые из них. Ясно, что это тоже не парадигма ООП.

Другие заверяют, что ООП — это Инкапсуляция, Абстракция и Сокрытие данных. Правда, разные источники скажут вам, что это всего лишь разные слова для описания одинаковой идеи. А другие скажут, что это три фундаментально разные концепции.

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

Давайте взглянем на другие парадигмы, позволяющие решать программистские задачи определенным образом. Процедурное программирование часто описывается как программы = данные + алгоритмы. Логическое программирование гласит: программы = факты + правила. Функциональное программирование, по всей видимости, программы = функции + функции. Что наводит на мысль, что ООП означает программы = объекты + сообщения. Так ли это? Я думаю, что тут теряется главное. А главное в том, что ООП – это не парадигма, как например процедурное, логическое или функциональное программирование. Вместо этого ООП говорит: “для каждой отдельной задачи вы должны разработать свою собственную парадигму”. Другими словами, парадигма объектно-ориентированного проектирования такова: “Программирование — это моделирование”.

2. Объектно-ориентированные языки программирования

Еще я не люблю то, как всем нравится не любить чужие языки. Мы любим разделять мир на лагери: фигурные скобочки против квадратных против круглых.

Вот некоторые вещи, которые говорились о наших любимых ООЯП:

“Си позволяет легко выстрелить себе в ногу; с C++ это сделать сложнее, но, когда вы это делаете, вы отстреливаете себе ногу целиком.”

Это сказал Бьерн Страуструп, так что все хорошо.

“Я придумал термин ‘объектно-ориентированный’, и вот что я вам скажу: я не имел в виду C++.” — Алан Кей.

“В C++ всего 2 вещи получились не так: начальный замысел и реализация.” — Бертран Мейер

“Внутри С++ сидит более компактный и понятный язык, отчаянно пытающийся выбраться наружу.” — Бьерн Страуструп

“C++ — это история, повторяющаяся как трагедия. Java — это история, повторяющаяся как фарс.” — Скотт МакКей

“Java, лучший аргумент за SmallTalk после C++.” — Фрэнк Винклер

“Если бы у Java был настоящий сборщик мусора, большинство программ удаляли бы себя во время исполнения.” — Роберт Сьюэл

И, возможно, наиболее всеобъемлющий приговор:

“Есть всего 2 типа языков: те, на которые все жалуются и те, которыми никто не пользуется.” — Бьерн Страуструп

3. Классы

Классы сводят меня с ума. Это может показаться странным, так что позвольте объяснить.

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

Однако в реальном мире есть только объекты. Классы существуют только в нашем сознании. Можете ли вы привести хоть один пример из реального мира, что класс — это реальная, физическая сущность? Нет, не думаю.

И вот в чем проблема. Вы когда-нибудь задумывались, почему программу на объектно-ориентированном языке понять настолько сложнее, чем на процедурном?

В процедурных программах процедуры вызывают другие процедуры. Процедурный код показывает… процедуры, вызывающие другие процедуры. Все хорошо и просто, так ведь?

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

Я думаю, поэтому SmallTalk’еры так любят программировать в дебаггере: последний дает им почуствовать контроль над исполняемыми объектами и позволяет программировать их напрямую.

Вот, что я бы хотел сказать разработчикам инструментов: пожалуйста, дайте нам IDE, которая будет показывать объекты вместо классов!

4. Методы

Честно говоря, методы я тоже терпеть не могу.

Как мы все понимаем, методы в хороших объектно-ориентированных программах должны быть короткими и изящными. Множество маленьких методов удобнее для разработки, понимания, повторного использования и так далее. Так в чем же проблема?

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

Одна из причин, почему мы тратим столько времени, в том, что нам приходится листать код туда-сюда… через множество маленьких методов.

Это также известно как синдром Затерянных в космосе и об этом говорится со времен создания ООП. Цитируя Адель Голдберг, “В SmallTalk все происходит где-то еще”.

Я уверен, что винить в этом стоит сегодняшние кодоориентированные IDE — учитывая, что объектно-ориентированный код не дает представлений об исполняемом приложении, IDE встает на нашем пути вместо то, чтобы помогать. Другая причина, по которой SmallTalk’еры так любят программировать в дебаггере — он помогает им хорошо видеть, какие объекты с какими взаимодействуют. Поэтому, я думаю, сегодня популярна разработка через тестирование (test-driven development, TDD), позволяющая увидеть взаимодействие объектов во время разработки.

И дело не в самом ООП — мы просто еще не поняли (после более чем 40 лет), как надо разрабатывать программы для него. Мы должны задаться вопросом: почему исходный код остается преобладающим отображением в IDE?

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

5. Типы

Ладно, признаю: я нетерпелив и ненавижу повторять слова дважды. Типы же заставляют меня это делать.

Кто-то сейчас наверняка подумал: “Но как же ты можешь писать на бестиповом языке. Ты никогда не будешь уверен, что твой код правилен.”

Конечно, “бестиповых” языков не существует — существуют статически и динамически типизированные. Статически типизированные мешают писать код в некоторых случаях. В принципе, ничего плохого в этом нет.

Проблема с самими типами, какими мы их знаем. Во-первых, они дают приводят к чувству ложной безопасности. То, что ваша Java программа компилируется, не означает, что в ней нет ошибок (и даже ошибок с типами).

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

И наконец, типизация плохо ладит с тем фактом, что существуют разные понятия типов. Не бывает одной всемогущей системы. Вспомните те страдания, которые мы испытывали с обобщениями в Java. Сейчас разрабатывается много полезных систем типов, но расширить Java, чтобы уместить их все, мы не можем. Гилад Браха предложил сделать типизацию не только необязательной, чтобы запускать программы даже в том случае, если типизация некорректна, но и подключаемой, такой, чтобы мы смогли подключать разные системы типов в разных частях наших программ. Мы должны подумать над этим предложением, а заодно и над тем, как адаптировать языки программирования и среды разработки к разнообразным системам типов.

6. Изменчивость

“Перемены неизбежны — в отличие от мелочи из торгового автомата.” — Роберт Галагер

Мы все не любим меняться, правда? А если так, то почему же жалуемся, если вещи не становятся лучше? Мы знаем, что полезные программы должны меняться, или со временем они ухудшаются.

(Между прочим, знаете, в чем разница между железом и софтом? Железо ухудшается, если вы не поддерживаете его в рабочем состоянии.)

Учитывая, что реальные программы должны меняться, справедливо полагать, что языки и IDE должны поддерживать это. Предлагаю вам, однако, назвать хоть один механизм в языках программирования, который поддерживает изменчивость. Те механизмы, которые работают с изменчивостью, скорее, ограничивают и контролируют ее.

Наш мир непостоянен, но мы хорошо себя в нем чувствуем. Контекст — вот то, что позволяет нам справляться с переменами. Мы подстраиваем наше поведение, наши ожидания под контекст, в котором находимся, но наши программы почему-то ломаются, если контекст меняется.

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

7. Шаблоны проектирования

Паттерны. Не могу с ними, не могу без них.

Каждый шаблон проектирования делает ваш проект запутаннее.

Я все сказал.

8. Методологии

“Все методологии основаны на страхе.” — Кент Бэк

Похоже, некоторые из моих студентов работают по Agile-методологии в стиле Чака Норриса:

“Чак Норрис не занимается итеративной разработкой. Все получается с первого раза, каждый раз.”

“Чак Норрис не пишет документацию. Он смотрит в упор на код до тех пор, пока тот не скажет все, что надо знать.”

9. UML

Бертран Мейер рассказывает о том, что его удивляло, почему схематические языки программирования всегда были такими популярными, пока однажды его не осенило: “Пузыри не ломаются!”. (Другое высказывание, принадлежащее Мейеру: “All you need is code”)

Похоже, что с тем, что обычно понимается под разработкой через моделирование, тоже что-то не так: не код должен генерироваться из модели — модель должна быть кодом.

Между прочим, FORTRAN продавался как язык высокого уровня, из которого генерировался исходный код. А теперь язык высокого уровня для нас и есть исходный код.

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

10. Очередная новая вещь

И наконец, коронная фраза, которую я ненавижу: “Объектов недостаточно. Нужно еще…”. Все эти годы нам нужны были фреймворки, компоненты, аспекты, сервисы (которые, похоже, любопытным образом вернули нас к процедурному программированию!)

Если объектов никогда не было достаточно, почему же они исправно служили нам все эти годы?

Вывод?

25 лет назад мы не ожидали, что “новый” феномен ООП проживет столь долго.
Мы думали, что ОО-конфереции типа ECOOP, OOPSLA просуществуют лет 5, а затем затеряются в мейнстриме.

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

ООП позволяет упрощать сложные вещи через моделирование, но мы все еще не овладели этим, возможно, потому, что плохо различаем существенные и несущественные сложности.

Чтобы двигаться дальше, мы должны сосредоточиться на изменчивости и на том, как ООП может содействовать изменчивости. Спустя столько лет мы все еще находимся в самом начале, пытаясь понять, что же ООП может предложить нам.

Спасибо за прочтение!

Немного об авторе
Oscar Nierstrasz — профессор Computer Science в Бернском университете, основатель Software Composition Group, которая исследует механизмы, позволяющие компьютерным системам быть гибче и лучше приспосабливаться к изменяющимся условиям. (отсюда понятно стремление автора к внедрению механизмов изменчивости в ЯП)

Активный участник исследовательского ООП-сообщества, участник и председатель таких конференций, как ECOOP, ESEC и MODELS. (Данная статья — как раз речь Oscar’а на конференции ECOOP 2010). Также главный редактор The Journal of Object Technology.

Соавтор более 200 публикаций и 2 книг: Object-Oriented Reengineering Patterns и Pharo by Example. (обе книги, по-видимому, не переведены на русский, зато бесплатны и доступны для скачивания по ссылкам)

Парадигмы ООП не существует или «Свободная касса!»

Эпотажный заголовок, не правда ли? Однако давайте разберемся.

Существует ли темнота? Не торопитесь. На самом деле нет: это просто отсутствие света. Её нельзя измерить, нельзя изменить, нельзя вообще ничего с ней сделать. Её нет как предмета. Если темнота «неполная», то это уже не темнота, а слабая освещенность. Освещенность можно конкретно измерить в люксах, единицы измерения темноты нет и быть не может.

Она существует только в нашем воображении. Так же как и парадигма ООП. 

Вы скажите, что так можно рассудить по отношению к любой другой парадигме. А вот и нет. У любой другой есть четкие определения и правила, по которым можно классифицировать код или идентифицировать его принадлежность. У ООП их нет.

К примеру Процедурная парадигма (её так принято называть по инерции, в PHP практически всегда используется её модификация — структурное программирование). Определение её недвусмысленно даже в банальной википедии:

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

Нужно отдать должное, та же википедия называет ООП не парадигмой, а методологией. Но суть собственно не в этом, а в том, что же есть на самом деле ООП.

Давайте представим себе ситуацию, что крутой ООПэшник устраивается на работу и проходит собеседование. А там такой зануда-очкарик в качестве интервьюера:

— Вы написали в резюме, что знаете ООП. Это верно?
— Да, разумеется.
— Расскажите, что такое ООП парадигма.
— Ну это парадигма программирования, основанная на классах и…
— Стоп. Вы хотите сказать, что в ООП обязательны классы? А как же JavaScript? Там нет классов, а ООП есть.
— Ммм, а, ну да. Не на классах, а на объектах и их взаимодействиях.
— Другими словами Вы утверждаете, что если программа содержит объекты, то это ООП?
— Нет, не просто содержит. А состоит только из одних объектов. Первый принцип концепции ООП, предложенный Аланом Кеем, которого считают его отцом-прородителем, гласит:
Всё является объектом.

— То есть Вы считаете, что кроме объектов в ООП ничего быть не может. Но как же тогда запустить программу? Создать экземпляр? Ведь оператор new, это процедурная директива.
— Ну… Да. 
— А другие опрераторы (instanceof к примеру), не являющиеся объектами, могут применяться в ООП?
— Могут, как же без них. 
— Но как же тогда постулат «всё является объектом»?
— Уточним:
Все должно является объектами, кроме нативных операторов и конструкций.

— А сам класс является объектом?
— Нет. Это абстрактный тип данных, на основе которого формируются объекты.
— Но он же может использоваться в парадигме?

— Да, разумеется. Как каркас для создания объектов.
— А статический класс PHP может использоваться в ООП?
— Нет. Ведь объект мы не создаем.
— А как же тогда паттерн Singleton? Или Registry?
— Действительно. Постойте, внутри языка все равно создается дефолтный объект, значит может использоваться.
— Но ведь ссылки на него нет и мы не можем работать с ним, как с полноценным объектом. Сериализовать, клонировать, передать аргументом и так далее. Значит это не совсем объект?
— Да, не совсем. Тогда нужно уточнить:
Всё должно являться объектами, кроме нативных операторов, конструкций и классов.

— Выходит программа, написанная на одних статических классах находится в рамках ООП парадигмы?
— Нет конечно. Это будет Класс-Ориентированное программирование 🙂
— Тогда как определить, что есть ООП программа? Если там 10 статических классов и один динамический объект, это ООП?
— Не думаю…
— А сколько? Каково процентное соотношение допустимо, чтобы считать программу Объектно-ориентированной?
— Не знаю. Это нигде не регламентировано.

— Получается, что наличие одних только объектов не обязательно, а сколько их должно быть — не регламентировано. Соответственно можно переформулировать так:
Объектно-ориентированная программа может использовать объекты, операторы и классы.

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

— Не совсем. Не обязательно должна их использовать, а тоже может.
— Значит другие парадигмы не могут? Это чисто индивидуальные признаки ООП?
— Эммм… Могут. Но есть же еще абстракция.
— Значит она будет являться эксклюзивной и обязательной фишкой?
— Вроде бы тоже нет. Не обязательно точно. Да и реализовать абстракцию можно даже на калькуляторе.
— Так как тогда сформулировать современную ООП парадигму? Так:
ООП программа может использовать объекты, нативные операторы, конструкции и сатические классы. А так же может  использовать полиморфизм, наследование, инкапсуляцю и абстракции.

— Что же изменилось?
— Почти ничего. Но постойте, дело скорее всего в состоянии. ООП предполагает некоторую многомерность вычислений на основе сохранения состояний объектов. 
— Вот. С этого места поподробнее.
— Дело в том, что объект может хранить свое состояние (значения свойств). И результат вычислений можно «замораживать», а так же изменять в ходе выполнения программы.
— Чем это отличается от обычных переменных в глобальной области видимости или от процедурной директивы static? 
— Тем, что это объекты.
— Но объекты можно использовать и в процедурной парадигме. Ведь они появились задолго до первой концепции ООП. Значит здесь тоже нужно конкретизировать и поставить обязательное условие:
ООП программа может использовать объекты, нативные операторы, конструкции и сатические классы. А так же может  использовать полиморфизм, наследование, инкапсуляцю и абстракции. Но обязательно должна сохранять состояние объектов на протяжении выполнения.

— Не получается… В ООП кроме понятия stateful есть еще и stateless. Модель stateful предполагает, что все методы объекта работают в контексте его состояния. В stateless общего контекста и состояния вовсе нет. Объекты похожи на библиотеки, сборники независимых функций.
— Но если сохранение состояния необязательно, а так же другим парадигмам «не запрещено» использовать объекты, то в чем соль? Давайте попробуем дополнить формулировку:
ООП программа может использовать объекты, нативные операторы, конструкции и сатические классы. Может  использовать полиморфизм, наследование, инкапсуляцю и абстракции. А так же может сохранять или не сохранять состояние объектов на протяжении выполнения.

— Это она может, но не обязательно. Похоже это на парадигму?
— Не особо.
— Так что же тогда еще есть?

— Остается только то, чего она не может. Или не имеет право.

— Что же именно?

— Можно я пойду… Всего доброго.

Вообще конечно же парадигма существует. Её разработал и анонсировал Алан Кей в лохматом 1972 году.  Но только она существует для чисто объектных языков. Таких как Smalltalk, для которого она и формулировалась. Звучит она так:

1. Всё является объектом.
2. Вычисления осуществляются путём взаимодействия (обмена данными) между объектами, при котором один объект требует, чтобы другой объект выполнил некоторое действие. Объекты взаимодействуют, посылая и получая сообщения. Сообщение — это запрос на выполнение действия, дополненный набором аргументов, которые могут понадобиться при выполнении действия.
3. Каждый объект имеет независимую память, которая состоит из других объектов.
4. Каждый объект является представителем класса, который выражает общие свойства объектов (таких, как целые числа или списки).
5. В классе задаётся поведение (функциональность) объекта. Тем самым все объекты, которые являются экземплярами одного класса, могут выполнять одни и те же действия.
6. Классы организованы в единую древовидную структуру с общим корнем, называемую иерархией наследования. Память и поведение, связанное с экземплярами определённого класса, автоматически доступны любому классу, расположенному ниже в иерархическом дереве.

Но все дело в том, что развитие ООП методологии ушло далеко в сторону от первоначальных идей. В Smalltalk действительно всё является объектом. Включая операторы, логические блоки и даже сами классы. И выполнение программы на этом языке заключается в обмене сообщениями между этими объектами. Кроме того, в нем очень жестко прописано наследование. Smalltalk начинается с одного суперглобального объекта Object, который является корнем древовидной иерархии всех остальных объектов.

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

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

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

Современное ООП, это конструктор ЛЕГО. На заре его изобретения использовались только несколько унифицированных взаимозаменяемых блоков, котрые можно было использовать в различных конструкциях. На то он и конструктор. Сейчас конструктор потерял основную концепцию, добавилась куча деталей, которые вообще не отвечают первоначальной идее. Допустим колеса к машинкам. Они вообще не блоки и совершенно непригоды для постройки дома. Если сравнить игроков в лего с программистами, то адепты «чистого» ООП норовят и эти колеса сделать из блоков, считая круглые детали чуждыми и называя «говнокодом».

Причем одни из них отрицают колеса для машин, но не против дверей и окон для домов. Другие же наоборот.

И еще, работа в компании, которая строго придерживается методологии ООП, лично мне напоминает работу в McDonald’s, а само ООП — фастфуд.

Точно так же нет общих прописанных концепций. И McDonald’s, и KFC, и даже банальный ларек с шавермой находятся в поле этой парадигмы. Нет никаких особых правил, однако объединяет их общий принцип. Быстро, по шаблону, с ограниченным ассортиментом. Ведь духовка дешевле, чем хороший повар. 

Очень высокая читабельность меню, так как гамбургер, он и в Африке гамбургер, пусть даже из мяса жирафа.

Очень легко рефакторится, достаточно добавить на булочку кунжут, и вот уже новое блюдо.

Легко тестируется, ведь не нужно дегустаторов, достаточно сравнить с эталонным чизбургером или бигмаком.

Тот же пиар, то же повcеместное распространение, та же популярность, тот же непретязательный уровень персонала.

Та же изжога, гастрит и ожирение у потребителей (низкая производительность и многословность). И те же восторженные возгласы тех, кто успел плотно подсесть.

И тот же «корпоративный дух». Не приведи Господи сказать работникам Макдональдса, что они травят население. Ты что! Они двигают прогресс, экономя время людей на еде. А кто не согласен — пусть идет жрать свою говно-яичницу с беконом и говно-борщ. А кому вообще неймется, пусть идет в ресторан и попробует разобраться в рецепте говно-супа Том Ям.

Так вот. Если вы считаете, что достигли вершин программирования, свято придерживаясь этих правил, оглянитесь и посмотрите вокуг внимательно. Весьма вероятно ваш удел всего навсего кричать «Свободная касса!» На просторах я нашел одно лаконичное определение назначению ООП (не знаю автора):

ООП есть корпоративные кандалы, средство держать часто полностью безграмотных кодеров в упряжке, только и всего. Если люди более лучшего качества, кандалы можно и нужно снять.

Скорее всего он перефразировал Пола Грэма:

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

Я вовсе не противник ООП методологии, как могло показаться. И тоже нет-нет, да и скушаю гамбургер с колой. Любая ложка хороша к своему обеду). Но загонять себя в искуственные рамки, которые при этом приходится самому для себя устанавливать — увольте. У современных языков программирования такие огромные возможности, что это было бы непростительным расточительством.

Такие авторитетные мэтры, как Пол Грэм, Ричард Габриел, Бьёрн Страуструп, Ричард Мэттью Столлман, наш соотечественник Александр Степанов и многие другие не стесняются признать себя адептами мультипарадигмы. Кто-нибудь посмеет назвать их говнокодерами? 🙂

В написани статьи использовались следующие материалы:

Objects Have Failed (Объекты провалились)
Why OO Sucks (не буду переводить 🙂 )
OOP Is Much Better in Theory Than in Practice (ООП гораздо лучше в теории, чем на практике)
История объектно-ориентированного программирования
Языки программирования через сто лет
Я не знаю ООП

и многие другие, всего не упомнишь.

Ну и конечно же наш любимый форум.

Николай aka twin

Парадигмы программирования

Сегодня мы разберемся что такое парадигмы программирования и отличительные черты каждого из них.

Определение парадигмы звучит обычно таким образом:

парадигмы это совокупность принципов идей и понятий которые определяют стиль написания компьютерной программы.

 также нужно отметить, что парадигмы бывают не только в программировании, но и в философии и т.д.

Отталкиваясь от определения можно сказать что парадигма программирования это определенный набор принципов для написания компьютерной программы.

Виды парадигм программирования

Так уж сложилось что многие программисты предлагали свои принципы, пути написания программы, и как следствие возникло большое количество парадигм.

Перечислим самые популярные из них:

• Императивное программирование
• Структурное программирование
• Декларативное программирование
• Объектно-ориентированное программирование

 На самом деле, есть ещё множество других парадигм, которые мы не перечислили в списке, мы охватываем лишь самые известные из них.

Кратко рассмотрим каждую из них

Императивное программирование

Самая первая парадигма, которая образовалась сразу же после появления компьютеров.

 от английского imperative — приказ

отличительные черты императивного программирования:

в исходном коде записываются «приказы» команды, а не классы, как в отличии например от объектно-ориентированного программирования.

Все инструкции должны выполняться последовательно, один за другим (например мы не можем перескакивать с одного участка кода на другой)

После выполнения инструкций данные могут записываться в память и считываться памяти.

Языки представители парадигмы: машинные (бинарные) коды,  Ассамблер, fortran, algol, cobol

Структурное программирование

 предложил этот метод нидерландский ученый

Эдсгер Дейкстра 1930 — 2002г

А вот основным в структурном программировании является понятие блоков и иерархической структуры и в которой используются три основных управляющих структур:

• последовательность
• цикл
• ветвление

Структурное программирование имеет также 7 принципов, описанный Дейкстрой:

1. полный отказ использования оператора goto; *
2. любая программа строиться на трех управляющих структурах последовальность, цикл и ветвление;
3. базовые управляющие структуры могут быть вложены в друг друга, как угодно;
4. Повторяющие компоненты, оформлять как подпрограммы;
5. каждая логическая структура следует оформлять как блок;
6. все структуры должны имеет один вход и один выход, и не более;
7. разработка программы должна идти пошагово «лестницей» (методом сверху вниз)

* —  goto — оператор безусловного перехода, который широко использовался в 1970-х

Интересна информатика? читайте также нашу лекцию системы счисления

Декларативное программирование

представляет собой спецификацию решения задачи, и описывает что такое проблема и ожидаемый результат от работы.

Противопоставляется императивному программированию потому что в декларативном программирование описывается что сделать, а в другом как сделать.

Объектно-ориентированное программирование (ООП)

является самым популярном и общеиспользуемой парадигмой  принятой во всем мире почти всеми  программистами. Всё промышленное программирование построено на этом. Основная идея заключается в том чтобы представить программу в виде объектов который в свою очередь представляет экземпляром класса, а классы в свою очередь образуют иерархию наследования.

Основные понятия ООП

Абстракция данных — выделение значимой информации и отделение её от незначимой.

Инкапсуляция — это такое свойство которое позволяет объединить данные, методы в классе

Наследование — свойство которое позволяет создать новый класс на основе старого (унаследовать все его свойства)

Полиморфизм — а это свойство позволяет использовать объекты с  одинаковым интерфейсом

Объект  — сущность в адресном пространстве появляющийся при создании экземпляра класса

Класс — универсальный тип данных состоящий из полей (наборов данных) и методов (как взаимодейтвовать с ними)

Список других парадигм можно продолжать долго, но мы рассмотрели только самые основные из них.

Также эта лекция доступна в видеоформате:

Помните, что вопросы можно задавать в комментариях.

4.2 / 5 ( 5 голосов )

Помогая проекту BEST-EXAM, вы делаете образование более доступным для каждого человека, внесите и вы свой вклад —
поделитесь этой статьей в социальных сетях!

Использование цикла — визуальная парадигма

Помимо шаблона элемента, существует еще один инструмент для запроса данных проекта и их размещения в документе, называемый инструментом цикла. Вы можете получить доступ к инструменту Loop на панели Element Template Pane .

Инструмент «Цикл» может запрашивать дочерний элемент элемента, выбранного в Diagram Navigator / Model Explorer . Когда вы выбираете и перетаскиваете инструмент «Цикл» на документ, вам будет предложено настроить цикл, например:

Элементы, перечисленные на вкладке Elements , являются дочерними элементами элемента, выбранного в Diagram Navigator / Model Explorer .Например, если вы выбрали диаграмму, вы можете ожидать, что элементы диаграммы будут перечислены здесь.

Контент будет добавлен в документ для каждого из перечисленных элементов. Создаваемый контент определяется шаблоном элемента. Вы можете выбрать шаблон на вкладке Element Types .

В левой части вкладки Element Types перечислены типы элементов, обнаруженных циклом, а в правой части — шаблон элемента, который будет выбран для создания контента.По умолчанию для всех типов элементов выбран шаблон Basic . Это означает, что для каждого из элементов на вкладке Elements контент будет создан и добавлен в документ на основе шаблона Basic . Вы можете выбрать другой шаблон, щелкнув Basic и сделав выбор.

Исключение элементов и типов элементов

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

Вы можете исключить элемент или тип элемента. Чтобы исключить элемент, наведите указатель мыши на этот элемент под вкладкой Elements и нажмите кнопку Exclude справа от наведенного ряда.

Чтобы исключить тип элемента, откройте вкладку Element Types и наведите указатель мыши на тип, который нужно исключить, затем нажмите кнопку Exclude .

Если вы хотите удалить элемент или тип элемента из списка исключений, откройте вкладку Excluded , наведите указатель мыши на элемент, который нужно удалить, а затем нажмите кнопку Include справа от наведенного курсора. ряд.

Сортировка

Чтобы изменить порядок элементов, щелкните раскрывающееся меню Sorting в верхней части окна New Loop и выберите способ сортировки.

Вот описание различных типов метода сортировки:

Сохранение шаблона цикла

Хотя цикл сам по себе является инструментом, а не шаблоном, из него можно создать шаблон. Это позволит вам дополнительно настроить шаблон, отредактировав цикл в форме XML.Чтобы создать шаблон цикла, щелкните правой кнопкой мыши любой блок содержимого, созданный с помощью инструмента «Цикл», и выберите Сохранить как шаблон цикла во всплывающем меню.

Вам будет предложено ввести имя шаблона. Введите имя и подтвердите. Когда закончите, вы найдете новый шаблон в списке на панели шаблонов элементов. Вы можете настроить его и повторно использовать при создании контента. Для получения подробной информации о написании шаблона, пожалуйста, прочтите Написание вашего шаблона.

.

Схема последовательности

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

Объект

В UML объект на диаграмме последовательности рисуется в виде прямоугольника, содержащего подчеркнутое имя объекта. Объект может быть назван одним из трех способов: имя объекта, имя объекта и его класс или просто имя класса (анонимный объект). Три способа присвоения имени объекту показаны на рисунке ниже.

Линия жизни

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

Имена объектов могут быть конкретными (например, myAccount) или общими (например, myAccount: Account). Часто анонимный объект (: Account) может использоваться для представления любого объекта в классе. У каждого объекта также есть своя временная шкала, представленная пунктирной линией под объектом. Сообщения между объектами представлены стрелками, указывающими от объекта-отправителя к объекту-получателю.

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

Сообщение

Сообщения, отображающие вызов операций, отображаются горизонтально. Они переходят от отправителя к получателю. Порядок указывается вертикальным положением, при этом первое сообщение отображается вверху диаграммы, а последнее сообщение — внизу.В результате порядковые номера не являются обязательными.

Тип линии и тип стрелки указывают на тип используемого сообщения:

1. Синхронное сообщение (обычно вызов операции) показано сплошной линией с закрашенной стрелкой. Это обычный вызов сообщения, используемый для нормальной связи между отправителем и получателем.
   
2. В ответном сообщении используется пунктирная линия с открытой стрелкой.
   
3. Асинхронное сообщение имеет сплошную линию с открытой стрелкой.Сигнал — это асинхронное сообщение, на которое нет ответа.
   

Сообщения о создании и уничтожении

Участники не обязательно живут на протяжении всего взаимодействия с диаграммой последовательности. Участники могут быть созданы и уничтожены в соответствии с передаваемыми сообщениями.

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

Сообщение деструктора уничтожает его получателя. Есть и другие способы указать, что цель уничтожена во время взаимодействия. Только если для уничтожения цели установлено значение «после деструктора», вы должны использовать деструктор.

Не мгновенное сообщение

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

Фокус контроля

Focus of Control представляет период, в течение которого элемент выполняет операцию. Верх и низ прямоугольника выровнены по времени начала и завершения соответственно

Обозначение итераций

Обозначение итерации представляет сообщение, которое отправляется много раз нескольким объектам-получателям, как это может происходить, когда вы выполняете итерацию по коллекции. Вы можете указать основу итерации в скобках, например * [для всех строк заказа].

Пример: разместить заказ

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

1. Шаги 1 и 2: Клиент создает заказ.
2. Шаг 3: Клиент добавляет товары в заказ.
3. Шаг 4, 5: Каждый предмет проверяется на наличие в инвентаре.
4. Шаг 6, 7, 8: Если товар есть в наличии, он добавляется в заказ.
5. Шаг 9 возврат
6. Шаг 10, 11: сохранить и уничтожить приказ

Фрагменты последовательности

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

Фрагмент последовательности представлен в виде прямоугольника, называемого комбинированным фрагментом, который включает в себя часть взаимодействий в диаграмме последовательности.Оператор фрагмента (в верхнем левом углу) указывает тип фрагмента. Типы фрагментов включают ref, assert, loop, break, alt, opt и neg, ref, sd.

Пример — сценарий размещения заказа

Член корабля, желающий разместить заказ онлайн.Заказанный товар будет отправлен участнику либо курьером, либо обычной почтой, в зависимости от его статуса участника (VIP, Обычное членство). При желании магазин отправит участнику уведомление с подтверждением, если участник выбрал опцию уведомления в заказе.

Visual Paradigm поддерживает диаграмму последовательности и другие типы диаграмм UML. Вы можете найти все необходимые инструменты для моделирования динамического поведения системы с помощью диаграммы последовательности.

Список литературы

1. Как нарисовать диаграмму последовательности в UML — Руководство пользователя Visual Paradigm

.

Введение в командное сотрудничество в визуальной парадигме

Командное сотрудничество — это практика работы в команде, а не одним человеком. Члены команды могут работать индивидуально над своими частями проекта и, в конечном итоге, объединять работы вместе, чтобы сформировать законченный проект. В результате сотрудничества между членами, использующего уникальные навыки каждого, работа может выполняться более эффективно и качественно.

Поддержка совместной работы

Visual Paradigm обеспечивает доступ к центральному репозиторию для управления проектами, совместного использования и управления версиями.Вы можете разрешить членам команды получать проект из репозитория, начинать работу над своими частями и разрешать им фиксировать (то есть загружать) свою работу на сервер, а также обновлять работы других. Visual Paradigm VPository и VP Teamwork Server являются поддерживаемыми стандартами систем управления версиями. В этой главе описаны некоторые ключевые концепции совместной работы в Visual Paradigm.

Управление участниками и проектами

Управление участниками и проектами — это процессы создания участников и проектов и определения прав доступа участников к проектам.

Касса и открытый проект

Checkout Project — это процесс получения проекта из репозитория для начала работы. Члены команды могут войти на сервер, а затем проверить проекты, с которыми они будут работать, при условии, что у них есть на это разрешение, предоставленное администратором. После этого откройте, чтобы начать работу над ним.

Подтвердить

Фиксация — это процесс загрузки изменений, внесенных в рабочую копию, на сервер.Когда члены команды вносят изменения в проект, они могут делиться своими работами, фиксируя эти изменения на сервере. Visual Paradigm попытается объединить изменения из рабочей копии в серверную копию. При слиянии может возникнуть конфликт, когда какие-либо изменения, внесенные одним из членов команды, вызовут неразрешимое противоречие с изменениями, внесенными другими. Член команды должен решить, сохранить ли его / ее изменение (т.е. перезаписать) или принять изменение коллеги (т.е. вернуться). Все конфликты должны быть разрешены, чтобы продолжить коммит.

Обновление

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

Конфликт

Конфликт — это ситуация, возникающая при фиксации или обновлении.Происходит при слиянии рабочей и серверной копии проекта, когда между ними обнаруживается противоречие. Например, член группы переименовал форму с A на B и зафиксировал изменение. Затем другой член группы переименовал ту же фигуру с A на C и попытался зафиксировать. Из-за разницы в названии формы возникает конфликт. Всякий раз, когда возникает конфликт, вы должны разрешить его или прервать операцию перед операцией фиксации / обновления.

Ответвление

Ветвление — это процесс создания ответвления из ствола (т. Е. Основного потока разработки) для изоляции изменений, которые не должны быть доступны в стволе ни в данный момент, ни навсегда. Работая в филиале, члены команды могут вносить неполные или рискованные изменения, не беспокоясь о риске повреждения работы в стволе. После проверки и подтверждения работ, выполненных в ветке, член команды может сделать изменения доступными в основной ветке путем слияния. Слияние также может выполняться от магистрали к ветви, чтобы гарантировать, что ветка всегда актуальна.

Маркировка

Тегирование — это процесс создания моментального снимка (т. Е. Тега) проекта во времени. Люди часто создают теги для архивирования выпусков произведений. Поэтому теги часто называют Release-1.0, где 1.0 — номер версии. Поскольку тег — это снимок, члены команды никогда не могут выполнить фиксацию под тегом.

История изменений

Каждый раз, когда член команды успешно выполняет фиксацию, создается новая ревизия как моментальный снимок проекта. Все больше и больше ревизий будет создаваться посредством повторной фиксации.Список ревизий, который показывает изменения проекта, называется историей ревизий. В Visual Paradigm вы можете просмотреть работы, выполненные в конкретных ревизиях, экспортируя их в файлы проекта. Вы можете определить различия между версиями, сравнивая их.

Отменить изменения

Возврат — это процесс отмены изменений. В поддержке совместной работы команды Visual Paradigm есть два типа действий возврата, которые вы можете выполнить. Первый — отменить локально измененные изменения, чтобы вернуть рабочую копию в исходное состояние.Еще одно действие возврата — это отмена изменений, внесенных в ревизии. Члены группы могут отменить изменения, внесенные в ревизии, отменив их.

Связанные ресурсы

Следующие ресурсы могут помочь вам узнать больше о теме, обсуждаемой на этой странице.

.

Visual Paradigm Обзор продукта

Visual Paradigm — это мощный кроссплатформенный, но простой в использовании инструмент проектирования и управления ИТ-системами. Visual Paradigm предоставляет разработчикам программного обеспечения передовую платформу разработки, позволяющую создавать качественные приложения быстрее, лучше и дешевле! Он обеспечивает отличную совместимость с другими инструментами CASE и большинством ведущих IDE, что превосходит весь ваш процесс разработки Model-Code-Deploy в этом универсальном решении.

Моделирование UML

Вы можете рисовать все виды UML 2.x в инструментах uml Visual Paradigm, которые включают:

Гибкая разработка

Примените UeXceler, методологию гибкой разработки в своем программном проекте. UeXceler включает в себя теорию и принципы, а также набор применимых гибких инструментов, которые помогут вам гибко создавать программную систему. Он включает гибкие инструменты, такие как карта пользовательских историй и таблица сродства, а также инструменты UX-дизайна, такие как раскадровка, каркасы и т. Д.

Дизайн базы данных

Для упрощения моделирования базы данных можно нарисовать следующие виды диаграмм:

Вы можете моделировать не только таблицу базы данных, но также хранимую процедуру, триггеры, последовательность и представление базы данных в ERD.

Помимо рисования ERD с нуля, вы можете реконструировать схему из существующей базы данных.

Помимо построения диаграмм, вы также можете синхронизировать диаграмму классов и диаграмму взаимосвязей сущностей для поддержания согласованности между ними.

Функция генерации SQL и выполнения доступна для мгновенного создания и выполнения оператора SQL из модели.

Моделирование бизнес-процессов

Для облегчения моделирования бизнес-процессов можно нарисовать следующие виды диаграмм:

Объектно-реляционное отображение

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

Сотрудничество в команде

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

• VP Teamwork Server (необходимо покупать Visual Paradigm Teamwork Server отдельно)

Документация производство

Быстрая разработка спецификации системы с помощью Док.Композитор. Для вас готов полный набор настраиваемых шаблонов документов.

Связанные ресурсы

Следующие ресурсы могут помочь вам узнать больше о теме, обсуждаемой на этой странице.

.