Файл: История и развитие методологии объектно-ориентированного программирования. Сферы применения (История и развитие методологии ООП. Сфера применения).pdf

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

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

Критические высказывания в адрес ООП:

• Было показано отсутствие значимой разницы в продуктивности разработки программного обеспечения между ООП и процедурным подходом^[16].
• Кристофер Дэйт указывает на невозможность сравнения ООП и других технологий во многом из-за отсутствия строгого и общепризнанного определения ООП [C. J. Date, Introduction to Database Systems, 6th-ed., Page 650].
• Александр Степанов в одном из своих интервью указывал, что ООП «методологически неправильно» и что «…ООП практически такая же мистификация, как и искусственный интеллект…» [http://www.stlport.org/resources/StepanovUSA.html].
• Фредерик Брукс указывает, что наиболее сложной частью создания программного обеспечения является «…спецификация, дизайн и тестирование концептуальных конструкций, а отнюдь не работа по выражению этих концептуальных конструкций…». ООП (наряду с такими технологиями как искусственный интеллект, верификация программ, автоматическое программирование, графическое программирование, экспертные системы и др.), по его мнению, не является «серебряной пулей», которая могла бы на порядок величины снизить сложность разработки программных систем. Согласно Бруксу, «…ООП позволяет сократить только привнесённую сложность в выражение дизайна. Дизайн остаётся сложным по своей природе…» [https://web.archive.org/web/20070315075634/http://inst.eecs.berkeley.edu/~maratb/readings/NoSilverBullet.html].
• Эдсгер Дейкстра указывал: «…то, о чём общество в большинстве случаев просит — это эликсир от всех болезней. Естественно, „эликсир“ имеет очень впечатляющие названия, иначе будет очень трудно что-то продать: „Структурный анализ и Дизайн“, „Программная инженерия“, „Модели зрелости“, „Управляющие информационные системы“ (Management Information Systems), „Интегрированные среды поддержки проектов“, „Объектная ориентированность“, „Реинжиниринг бизнес-процессов“…» [http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html].
• Никлаус Вирт считает, что ООП — не более чем тривиальная надстройка над структурным программированием и преувеличение её значимости, выражающееся, в том числе, во включении в языки программирования всё новых модных «объектно-ориентированных» средств, вредит качеству разрабатываемого программного обеспечения.
• Патрик Киллелиа в своей книге «Тюнинг веб-сервера» писал: «…ООП предоставляет вам множество способов замедлить работу ваших программ…».
• Известная обзорная статья проблем современного ООП-программирования перечисляет некоторые типичные проблемы ООП [http://blogerator.ru/page/oop_why-objects-have-failed]
• В программистском фольклоре получила широкое распространение критика объектно-ориентированного подхода в сравнении с функциональным подходом с использованием метафоры «Королевства Существительных» из эссе Стива Йегги [http://steve-yegge.blogspot.com/2006/03/execution-in-kingdom-of-nouns.html].

---

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

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

---

Например, Пол Грэм говорит:

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

Хотя иногда объектно-ориентированный код действительно годится для повторного использования, таким его делает вовсе не объектно-ориентированность, а программирование в стиле „снизу вверх“. Возьмём, например, библиотеки: их можно подгружать и повторно использовать сколько угодно, потому что, по сути, они представляют собой отдельный язык. И при этом, совсем неважно, написаны ли они в объектно-ориентированном стиле или нет.»

Другой крупный критик ООП — это известный специалист по программированию — Александр Степанов, который работая в Bell Labs участвовал в создании C++ вместе c Бьерном Страуструпом, а впоследствии, уже по приглашению в HP Labs, написал Standard Template Library (STL).

Александр Александрович полностью разочаровался в парадигме ООП, в частности он пишет:

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

Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы приходите к тому, что вы в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг — из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле».

Ричард Столлман также известен своим критическим отношением к ООП, особенно он любит шутить насчет мифа объектников что ООП «ускоряет разработку программ»:

«Как только ты сказал слово „объект“, можешь сразу забыть о модульности»

«ООП ради самой ООП уже давно превратилось в замкнутый круг. Конечно, можно считать C# в .NET 3.5 с более чем 50,000 реализованных классов „венцом эволюции“. Добавить в следующей версии .NET ещё миллион классов — что может быть более правильным и более вожделенным, с точки зрения ООП-программиста? Говорите, это и есть то самое бегство от сложности?»

Java/C# не являются ни развитием, ни «осознанием ошибок» C++. Они взяли наихудшую парадигму из языка и возвели ее в степень настоящей догмы. А именно — идею наследования.

---

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

Томас Поток из MIT даже провел масштабное прикладное исследование [http://www.csm.ornl.gov/%7Ev8q/Homepage/Papers%20Old/spetep-%20printable.pdf], которое продемонстрировало, что нет никакой заметной разницы в производительности между программистами работающими в ООП и в обычном процедурном стиле программирования. «Это просто миф, который отлично работает вкупе с невежеством масс — если вы никогда не видели ничего кроме ООП, как же вообще вы можете в ней сомневаться?».

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

Ещё один ветеран программистского ремесла, Джоэл Спольски, рассказывает, что во время его работы в Microsoft его так достали тамошние адепты-инженеры ООП, что даже сейчас, по прошествии почти десяти лет, его передергивает от людей, «с головой погрязших» в этой парадигме. Джоел — автор популярного в англоязычной литературе шутливого термина Архитектурные Астронавты, который пошел гулять из его популярной статьи «Не дайте Астронавтам Архитектуры вас запугать» [http://www.gnuman.ru/joel/Ne_dajte_Astronavtam_Arhitektury_vas_zapugat/], посвященной именно тем самым архитекторам-инженерам из Microsoft, которые так упорно преследовали Джоела со своими абстрактными ООП-концепциями и шаблонами.

Ричард Гэбриел, позже, заново систематизировал, с учетом имевшего место широкого обсуждения и критики, после чего все было сведено в брошюру, которую Ричард выложил в свободный доступ [http://blogerator.org/go.php?url=http://www.dreamsongs.com/Files/ObjectsHaveFailed.pdf] вместе с поясняющими её слайдами [http://blogerator.org/go.php?url=http://www.dreamsongs.com/Files/ObjectsHaveFailedSlides.pdf].

---

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

Заключение

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

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

• Thomas E. Potok, Mladen Vouk, Andy Rindos. Productivity Analysis of Object-Oriented Software Developed in a Commercial Environment (англ.) / — 1999. — Vol. 29, no. 10.
• Бруно Бабэ. Просто и ясно о Borland C++: Версии 4.0 и 4.5 Пер. с англ. / Бабэ Бруно -М.: БИНОМ, 1994. - 400с.
• Буч Г. «Объектно-ориентированный анализ и проектирование с примерами приложений на С++» Пер. с англ. / Г. Буч - М.: Бином; СПб.: Невский диалект, 1999.
• Жуков А. «Изучаем С» / А. Жуков - СПб.: Питер, 2003.
• Ишкова Э. «С++ начала программирования» / Э. Ишкова - М.: Бином, 2001.
• Клочков Д.П., Павлов Д.А. Введение в объектно-ориентированное программирование. Учебно-методическое пособие. / Д.П. Клочков, Д.А. Павлов - Изд. Нижегор. ун-та, 1995. - 70с.
• Мухортов В.В., Рылов В.Ю. Объектно-ориентированное программирование, анализ и дизайн (методическое пособие) / В.В. Мухортов, В.Ю. Рылов - ИМСО РАН, Новосибирск, 2002
• Страуструп Б. Язык программирования С++ (2-ред). Пер. с англ. / Б. Страуструп -М.: Радио и связь, 1995. - 352с.
• Шилдт Герберт. Самоучитель С++ (2-ред). Пер. с англ. / Герберт Шилдт - СПб.: BHV-Санкт-Петербург, 1997. -512с.
• Элиас М., Страуструп Б. Справочное руководство по языку С++ с комментариями. Пер. с англ. / М. Элиас, Б. Страуструп - М.: Мир, 1992. -279с.

---