Сопоставление и взаимосвязь сруктурного и объектно-ориентированного программирования

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

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

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

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

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

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

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

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

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

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

Исследование Thomas E. Potok, Mladen Vouk и Andy Rindos показало отсутствие значимой разницы в продуктивности разработки программного обеспечения между ООП и процедурным подходом.

Кристофер Дэйт указывает на невозможность сравнения ООП и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП.

Александр Степанов, в одном из своих интервью, указывал на то, что ООП «методологически неправильно» и что «… ООП практически такая же мистификация как и искусственный интеллект…».

Фредерик Брукс (Frederick P. Brooks, Jr.) в своей статье «No Silver Bullet. Essence and Accidents of Software Engineering» (Computer Magazine; April 1987) указывает на то, что наиболее сложной частью создания программного обеспечения является « … спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины (то есть примерно в 10 раз, как говорится в статье) снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…».

Эдсгер Дейкстра указывал: «… то о чём общество в большинстве случаев просит - это змеиное масло. Естественно, «змеиное масло» имеет очень впечатляющие имена, иначе будет очень трудно что-то продать: «Структурный анализ и Дизайн», «Программная инженерия», «Модели зрелости», «Управляющие информационные системы» (Management Information Systems), «Интегрированные среды поддержки проектов», «Объектная ориентированность», «Реинжиниринг бизнес-процессов»…».

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

Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «… объектно-ориентированное программирование предоставляет вам множество способов замедлить работу ваших программ …»

Известная обзорная статья проблем современного объектно-ориентированного программирования перечисляет некоторые типичные проблемы объектно-ориентированного программирования.

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

1. Критика рекламы объектно-ориентированного  программирования.

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

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

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

3. Производительность объектно-ориентированных  программ.

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

4. Критика отдельных технологических  решений в объектно-ориентированных-языках  и библиотеках.

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

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

1.Динамическое связывание методов.

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

2.Значительная глубина абстракции.

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

3.Наследование «размывает» код.

Код, относящийся к «оконечным» классам иерархии наследования (которые обычно и используются программой непосредственно) - находится не только в самих этих классах, но и в их классах-предках. Относящиеся к одному классу методы фактически описываются в разных классах. Это приводит к двум неприятным моментам:

- снижается скорость трансляции, так как компоновщику приходится подгружать описания всех классов иерархии;

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

4. Инкапсуляция снижает скорость  доступа к данным.

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

5.Динамическое создание и уничтожение  объектов.

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

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

3.5. Проблемы преподавания структурного  и объектно-ориентированного программирования

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

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

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