Прошло ровно 10 лет после публикации известной и классической в мире программирования статьи, написанной Ричардом Гэбриелом, название которой стало уже нарицательным и вынесено в заголовок этого материала. Статья стала настолько острой и злободневной для своего времени, что вызвала бурный всплеск обсуждений в сообществе программистов, целый ряд известных программистов включились в открытую полемику с автором - от редакции известнейшего американского программистского журнала "Др.Добс" до таких ученых, как Энди Танненбаум.
Автор этой нашумевшей статьи, доктор компьютерных наук Стэнфорда, старший архитектор по разработке ПО сначала Sun, а потом и IBM, Ричард Гэбриел (www.dreamsongs.com/Bio.html), никогда не скрывал своего скептического отношения к парадигме ООП. В 2002 году, по прошествии двух лет после первоначальной публикации своей критической статьи, автора пригласили выступить, теперь уже живьем и перед большой аудиторией, и изложить свои критические взгляды на ежегодной конференции OOPSLA (Центральная конференция IT-специалистов по объектно-ориентированным языкам и методологиям разработки ПО, en.wikipedia.org/wiki/OOPSLA). И, чтобы по старой доброй американской традиции превратить это в горячее шоу, в качестве его оппонента одновременно пригласили Гая Стили (en.wikipedia.org/wiki/Guy_L._Steele), отца-разработчика языка Scheme, крупнейшего специалиста-теоретика по ООП, авторитет которого в американской академической среде непререкаем. Чтобы максимально отразить позиции выступающих, их решили усилить ещё двумя. В качестве "анти-объектника" дополнительно пригласили Пола Грэма (en.wikipedia.org/wiki/Paul_Graham_(computer_programmer)), крупнейшего специалиста по Lisp, автора многочисленных книг и стандартизаций Lisp, кстати, согласно Википедии, в 1995 году создавшего вместе с Робертом Моррисом первое в мире web-приложение - Viaweb (en.wikipedia.org/wiki/Viaweb), которое затем выкупила у них Yahoo (как мы все знаем, Роберт Моррис, близкий друг и коллега Пола, на этом достижении не остановился и написал, пожалуй, самый знаменитый червь в истории Интернета, но это уже совсем другая история). В стан объектников пригласили Джеймса Ноубла, автора одних из первых книг и работ по теории ООП. Многие участники вспоминают, что конференция этого года надолго запомнилась им по тому уровню обсуждения, которое завязалось тогда в этой публичной "интеллектуальной дуэли" фактически диаметрально разных школ программирования. Но факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp'еров была куда убедительней и последовательней, чем сторонников ООП (любопытно, что главным докладчиком по ООП был создатель языка Scheme (en.wikipedia.org/wiki/Scheme_(programming_language)) - главного современного диалекта того же Lisp'а).
Пол Грэм утверждал, что половина всех концепций ООП являются, скорее, плохими, чем хорошими, в связи с чем он искренне сочувствует ООП-программистам, тогда как вторая половина от оставшихся концепций и вовсе не имеет никакого отношения к ООП, с которыми их почему-то постоянно ассоциируют. Например, он говорит: "В восьмидесятых годах метод повторного использования каким-то неясным мне образом связали с объектно-ориентированным программированием, и сколь угодно многочисленные имеющиеся доказательства обратного, по-видимому, уже не избавят этот метод от этого клейма. Хотя иногда объектно-ориентированный код годится для повторного использования, таким его делает вовсе не объектно-ориентированность, а программирование в стиле "снизу вверх". Возьмём, например, библиотеки: их можно подгружать и повторно использовать сколько угодно, потому что, по сути, они представляют собой отдельный язык. И при этом совсем неважно, написаны они в объектно-ориентированном стиле или нет". Другой крупный критик ООП - это известный специалист по программированию Александр Степанов (en.wikipedia.org/wiki/Alexander_Stepanov), который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом, а впоследствии, уже по приглашению в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП, в частности, он пишет: "Я уверен, что ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. То же самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг - из-за ущербности парадигмы вы просто обречены на переписывание программы уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле". Ричард Столлман также известен своим критическим отношением к ООП, особенно он любит шутить насчет мифа объектников, что ООП "ускоряет разработку программ": "Как только ты сказал слово "объект", можешь сразу забыть о модульности". Томас Поток из MIT даже провел масштабное прикладное исследование (www.csm.ornl.gov/~v8q/Homepage/Papers Old/spetep- printable.pdf), которое продемонстрировало, что нет никакой заметной разницы в производительности между программистами, работающими в ООП и в обычном процедурном стиле программирования.
Почти все пункты своего выступления и претензии к ООП как к парадигме Ричард Гэбриел позже заново систематизировал с учетом имевшего место широкого обсуждения и критики, после чего все было сведено в брошюру (www.dreamsongs.com/Files/ObjectsHaveFailed.pdf), которую Ричард выложил в свободный доступ вместе с поясняющими их слайдами (www.dreamsongs.com/Files/ObjectsHaveFailedSlides.pdf, очень краткое содержание его выступления можно найти и в переводе на русский язык: bugtraq.ru/library/programming/objectshavefailed.html). После этого очень сильного выступления у него появилось много последователей, которые попытались систематизировать все мифы и дефекты ООП в своих многочисленных статьях и работах (www.devx.com/DevX/Article/26776, www.geocities.com/tablizer/oopbad.htm, www.softpanorama.org/SE/anti_oo.shtml). К сожалению, вероятно, из-за того, что, как я уже сказал выше, ответное выступление объектников "Почему ООП не провалилось" получилось несколько скомканным из-за интеллектуального натиска Lisp'еров, выступающие так и не оформили впоследствии свою позицию преимуществ ООП в развернутом виде. В Интернете сохранилось лишь краткое содержание-конспект их выступления, которое также существует как в английской оригинальной версии (www.dreamsongs.com/ObjectsHaveNotFailedNarr.html), так и в русском переводе (bugtraq.ru/library/programming/objectshavenotfailed.html).
Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла "тихая революция". Молодые сторонники теории относительности, массово пришедшие в номенклатуру университетов, тогда постепенно захватили власть в области преподавания физики, навязав свою, столь любимую интеллектуалами того времени теорию относительности широким массам физиков. На самом деле в то время имелись как положительные эксперименты и опыты, подтверждающие существование эфира, так и отрицательные. Первые были полностью проигнорированы и исключены административными мерами из всех учебников физики, после чего эфир был незаслуженно "закрыт" и отправлен в отставку, и вот уже нынешнее поколение студентов-физиков даже и не знает о тех весьма успешных опытах по обнаружению эфирного ветра. "Ну и где мы теперь, с этой вашей красивой теорией относительности, кто-нибудь может мне назвать хоть какие-то реально-практические результаты её применения в вашей обыденной жизни после целого века её ковыряния и массового насаждения?", - как всегда язвительно вопрошает Гэбриел. По мнению Ричарда, то же самое произошло и с ООП, которая в 80-х годах была провозглашена "серебряной пулей" в "борьбе со сложностью программистского бытия", искусственно и безальтернативно навязана в академической среде, причем мифы, которые кочуют из учебника в учебник по ООП, "часто забавны и высосаны буквально из пальца".
Только время покажет, кто в итоге окажется правым, а кто в этой горячей методологической дискуссии искренне заблуждался. Но в любом случае, лично я за то, чтобы у нас всегда оставались возможности для альтернативных взглядов, пусть даже отличных от выбора большинства (как провокационно замечают американцы в таких случаях, "лемминги не могут ошибаться"). И да, будьте смелее в своих поисках и размышлениях, не нужно бояться, если в очередной раз в истории вдруг окажется, что... "король-то голый"!
Игорь САВЧУК,
Blogerator.ru
Версия для печати
Комментарии
Страницы
http://blogerator.ru/page/oop_why-objects-have-failed
Так вот, написание кода - это мелочи. Это 5-10% времени и стоимости разработки. Сотни миллиарды долларов и миллионы человеко-лет (без преувеличения), как в трубу, вылетают на поддержание (тестирование, правку багов) софта. Вот это и есть настоящая проблема. Да еще программисты наповадились с места на место бегать каждые 2-4 года, -- только человек освоится и годик поработает продуктивно, -- глядишь, он уже опять куда-то намыливается... И вот тут возникает интересная проблема. В связи с высокой текучестью кадров и большой сложностью реальных проектов читаемость и модифицируемость кода приобретает первостепенное значение!
Чтобы код был читаем и легко модифицируем, крайне желательно, чтобы он был локально понятен. Так, чтобы новый человек, посмотрев на процедуру, смог достаточно быстро понять, что она делает и как. И вот тут, в объектно-ориентированных языках типа Java, С# начинается веселье с конструкторами, деструкторами, виртуальными функциями, наследованием, монстроидальным шаблонным метапрограммированием, полиморфизмом, исключительными ситуациями... Увидев вызов простой функции, как правило сразу понятно что происходит, можно сходить и посмотреть, что она делает. В объектно ориентированных языках, где народ (в особенности вчерашние студенты) любят, ой как любят переоперделять функции, не поймешь, какой из 15 виртуальных методов будет вызван в данном контексте, и читать текст их всех дело утомительное. В результате починка бага занимает в 3-5 раз больше времени.
Перейдем к деструкторам и конструкторам. Видит программист описание локальной переменной, которая нигде не используется, и, не сомневаясь, удаляет его. Программа перестает работать. Что случилось? Оказывается, конструктор этой переменной устанавливает связь с другим объектом. Конечно, за такие фокусы (я имею в виду создание такого конструктора) нужно увольнять, но что написано пером - не вырубишь топором. В результате программист (по-хорошему) вынужден прочитать описания всех конструкторов и деструкторов по всей цепочке наследования всех локальных cтруктурных переменных процедуры. Кому хочется шариться по 40 файлам, чтобы понять, что делается в процедуре? — да никому. Никто этого и не делает, в результате через 3 года в программе, лихо написанной на объектно ориентированном языке, не разберется никто. Посему, и надежность программ, размашисто написанных на таких языках, оставляет желать лучшего. Я уже не говорю про перекрытие операторов, конструкторов копирования и прочее. Творческое пользование темплейтами также сможет доставить потомкам немало приятных минут. А чего стоят исключительные события? Почему-то получается, что код, написанный на языке программирования без скрытого поведения, поддерживать и сопровождать гораздо легче. Просто уже потому, что вероятность наступить на грабли меньше. Описана переменная -- можно быть уверенным, что ничего больше это не означает. Вышли из блока -- значит, вышли, и нечего кроме. Что написано, то и происходит. Когда же приходится докапываться до третьего слоя истины -- это бардак. К сожалению, на объектно ориентированных языках наломать дров проще простого, что мы и наблюдаем изо дня в день.
Как это ни удивительно, при промышленном программировании залогом хорошего здоровья является простота. Чем проще, тем лучше. Код должен быть понятен, иначе человек, который заменит Вас через 2-4 года, не справится. Хотите проинициализировать переменную? Вызовите процедуру. Надо вызвать функцию? Вызовите ее напрямую. Очевидно, что чем проще язык программирования, тем трудней сделать на нем семантическую ошибку. Если достаточно полное и предельно краткое описание языка занимает около 1000 страниц, можно ли ожидать, что рядовой программист будет знаком хотя бы с 50% особенностей языка? -- навряд ли. Тогда откуда может быть уверенность, что достаточно навороченная конструкция представляет собой именно то, что хотел сказать программист?
Далее. Стандартные библиотеки. Опять же, с точки зрения промышленного программирования, — чем проще, тем лучше. Если в стандартной библиотеке (к тому же динамически подгружаемоей) есть баг, то это беда. Если программисты его не нашли -- значит, найдут пользователи. Если нашли и обошли, то проблемы начнутся после того, как пользователь обновит библиотеки и в новой версии баг будет починен. Наконец, необходимым требованием является 100% обратная совместимость библиотек. Ну скажите мне, хоть одна библиотека для Java удовлетворяет этому требованию? А есть ли там хоть одна процедура без какого-либо ляпа? Я уже не говорю о вопросах совместимости, инсталляции и прожорливости разных версий фреймворков под C# .NET и о том, что на изучение постоянно изменяющихся спецификаций различных новомодных библиотек может уйти полжизни, не говоря уже о проблемах стабильности их работы на практике.
Смежная проблема. Возраст языка. Чем старше язык, тем лучше и глубже его знают программисты. Всем известно, что можно делать, чего нельзя, а что можно, но лучше не нужно. С новомодными языками дело обстоит сложней, и опыт, равно как устав караульной службы, пишется кровью программистов. Наконец, не следует забывать, что разработчики компиляторов тоже не боги и могут ошибаться, а чтобы найти баги в компиляторе с Java или, в особенности Сановском, напрягаться не нужно - баги Вас сами найдут.
Вообще, за последние 20 лет вышла масса литературы на тему дизайна программного обеспечения. Авторы книг статей постарались на славу. Были выделены и формализованы основные конструкции в виде паттернов проектирования. Сформированы основные практики и рекомендации. Однако, у этой большой и красивой медали есть обратная сторона – очень редко говорится О РЕАЛЬНОЙ НЕОБХОДИМОСТИ ПРИМЕНЕНИЯ тех или иных методик, а также о трудозатратах при этом. Подавлющая масса молодых программистов из-за отсутсвия опыта воспринимает все подобные материалы совершенно неадекватно, стремясь де-факто реализовать в одном месте практически все то, о чем они когда-либо читали и слышали (а слышали они в силу возраста как раз все последние веяния). Им трудно дифференцировать рациональные зерна от бесполезных "бантиков" и программирование превращается не столько в создание требуемого функционала, сколько в продумывание деталей как это будет написано. Внешнее и второстепенное выдвигается на первое место. Значительную часть времени начинает занимать бесполезный рефакторинг программного текста и мысли о том как же организовать очередное хитрое зацепление классов, в то время как создание полезнго функционала уходит на задний план. Например, в игровой индустрии подобные повадки особенно вредны. Нужен функционал, не нужен лишний текст. 99% текста выполняют 100% работы.
Например, когда-то одному разработчику был дан проект очень незатейливой игры. Предполагалось, что эта игра займет около месяца разработки. Но месяца не хватило. Спустя шесть недель выяснилась причина. Программист попался очень педантичный и вместо того чтобы взять чистый СИ и написать игру, он 80% времени занимался тусовкой классов в сложнейшей иерархии. Когда посчитали – оказалось порядка 210 классов. Движок получился, была написана чудовищная гора текста. В объекты было завернуто все, начиная от объектов межпоточной синхронизации и кончая экранными виджетами со своей собственной системой сообщений. Да только вот беда — сама игра была в совершенно зачаточном состоянии и не работала. Старые игры для GBA, C64, NES, SNES, Megadrive, ZX Spectrum, Atari, N64 всегда, с неизменным постоянством работали как часики. Можно конечно сейчас сказать "ну знаешь ли, не сравнивай сложность продуктов". А ничего подобного! Просто нужно знать как писались эти вещи и на чем писались. Раньше ведь даже не было IDE, и дебаггеров с одним тычком мыши. Не было самих мышей. Загружались с дискет (а еще раньше с кассет!). Иногда не было возможности отлаживаться или даже запускать код на самом устройстве. Так может уделять внимание эффективности, задачам которые пытаемся сделать?
Информация к размышлению: http://www.softpanorama.org/SE/anti_oo.shtml
Всё НЕВЕРНО изложено ибо неверно понято.
ООП - это НЕ означает СЛОЖНО. - Это НЕ синоним слов "СЛОЖНОЕ ПРОГРАММИРОВАНИЕ". - нет!
"Плоский С" - он же в тексте "простой (обычный) С" - не синоним слов "ПРОСТОЕ ПРОГРАММИРОВАНИЕ" - нет!
На языках ООП можно писать как сложно, так и совершенно просто!
И на "плоском С" можно писать как сложно, так и совершенно просто!
Если писать на "плоском С" и имплементировать(осуществить), к примеру, все возможности языка ООП, то у вас получиться СЛОЖНАЯ программа (система)написанная на "плоском С", пользоваться которой будет очень сложно, по сравнению с написанием на языке ООП.
Ещё раз - "простой язык (не ООП)" - не означает, что на нём нельзя написать сложные(!) программы, сложные в смысле сложности понимания - то есть сложно-понимаемые программы.
ООП, как парадигма языка, родилась НЕ сдуру и НЕ зненацку. - Когда программисты, пишущие, к примеру, на "простом С", стали писать свои сложные(!) библиотеки, которые фактически начали оперировать псевдообъектами на "простом С", но с которыми было ТРУДНО работать, так как приходилось соблюдать(и изучать) все правила и приёмы обращения с кодом, для каждой из библиотек всё же отличающихся, но чем то похожие по сути, тут то и возникла мысль, а не поручить ли отслеживание(!) всех этих правил и методов программирования самому компилятору(или интерпретатору) через написание на языке(!) парадигмы ООП. - Что и было сделано.
Язык ООП - это фактически УПРОЩЕНИЕ(а не усложнение, как считает автор) - упрощение работы(!) по программированию, работы со всеми этими библиотеками, написанными на "простом("плоском") С" и осуществлявшими фактически парадигму ООП (хоть и закодированную в кодах "плоского С"). - По крайней мере так родился С++ (конечно не без влияние "чистых" языков ОПП, где ВСЁ есть объект).
Но так как С++ всё же наследовал "рудименты" С, то эти рудименты приходилось учитывать при программировании, что приводило к правилам их учёта (а их несоблюдение к ошибкам, иногда трудно уловимым).
Тогда родились почти "чистые" языки ООП, типа Java - где всё же НЕ ВСЁ есть объект! - там есть и примитивы.
Ещё раз - "примитивный, простой, не ООП язык" не есть синоним слов "простая программа"! - Это заблуждение как ваше, так и миллионов программистов. имхо
Вы можете взять язык, который состоит из десятка операторов (никаких конструкторов и прочего...) - "занесение в память", "чтение из памяти", "сдвиг" и прочее типа того и породить СЛОЖНЫЕ программы, когда на этом языке напишите к примеру алгоритмы умножения и деления.
ООП не есть сложно, ООП есть УПРОЩЕНИЕ написания программ за счёт того, что контроль за правилами передали компилятору - то есть другой программе, а не голове человека, который ранее должен был всё это держать в этой голове и соблюдать эти правила, при написании сложнейших алгоритов на "простом языке"!
P.S. - А можно ли на языке ООП писать просто? - Запросто, когда я спросил одного чела, почему он, используя технику "копи и пасте" дублирует один и тот же код по всем классам, он мне ответил, - Если надо будет потом исправить в этом коде что-то, то он текстовым редактором найдёт(!) все места, куда он вставил этот дублирующий код и везде(!) поправит. ;-)
И не колышет его, что такой метод не не есть ООП. ;-)
А почему он так делает? - А потому что сейчас IDE позводяет ему быстро найти в коде все(!) места где он для "простоты" продублировал какой-то кусок своего кода.
Вот вам и "простое" программирование на языке ООП(!), - и это та простота, о которой можно сказать - "простота, которая хуже...". имхо
ООП позволяет делать подобное не программеру, а ...пользователю. Кто этого не понял -- не понял преимуществ ООП.
Разумеется. Речь была о том, как проще программисту сработать создание пользователем набора с параметризацией его элементов из базового комплекта.
Комментарии в основном - бред, написанный страдающими синдромом утенка ( http://lurkmore.ru/%D0%A1%D0%B8%D0%BD%D0%B4%D1%80%D0%BE%D0%BC_%D1%83%D1%82%D0%B5%D0%BD%D0%BA%D0%B0 ). Пройдусь по верхам.
ООП - это не свойство ЯП, это методология архитектуры, ЯП может лишь предоставлять синтаксический сахар для нее. На "плоском С" точно так же реализуется ООП. Виндовое ядре реализует основные концепции ООП, хотя написано на голом С.
Про конструктор-деструктор.. Если для вас когдато RAII оказался в новинку - это не значит что RAII г-но. RAII очень даже крут, позволяя вместо 3х-этажных try..finally и goto обходиться 1й локальной переменной. Кстати этого мне ОЧЕНЬ не хватает в C# и жабе.
А быдлокодить можно пользуясь любыми средствами.
Страницы