Прошло ровно 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
![Версия для печати Версия для печати](https://www.kv.by/sites/all/modules/print/icons/print_icon.png)
Комментарии
Страницы
Человека, могущего "кодить любыми средствами" и выбирающего средства, адекватные задаче - я бы не назвал "быдлокодером"...
К противникам-пуристам разумеется.
/*Человека, могущего "кодить любыми средствами" и выбирающего средства, адекватные задаче*/
Никаких претензий к умеющим кодить. Смысл в том что если вы видите былокод в котором встречаются ключевые слова class, virtual etc - это не значит что ООП - быдлоподход. Это лишь значит что этот конкретный код писал быдлокодер.
Бред -- хлеб журнализдики! Молодец, автор, забористо, хотя и римейк.
bred is bread? ;-)
Дело в том, что трудности ООП возникли по причине того, что программисты достигли ПОСТМОДЕРНИЗМА (как ранее математики и потом физики).
Объекты перестали быть простыми (типа окно, кнопка, канва и пр.) и стали фактически абстрактными. Их состав (методы их) и их место в общей структуре объектов(объектного графа) перестали иметь всякий внешний(!) и понятный смысл став просто неким АБСТАКТНЫМ объектном, удобным для программиста (просекающего ООП) и абсолютно неясными другим.
Даже возникает проблема подыскать имя классу, - имя, которое хоть что-либо бы значило.
Значит одно из двух - либо класс ничего полезного не делает либо делает слишком много полезного.
В первом случае он не нужен, а во втором - необходимо провести его декомпозицию на более мелкие классики.
Interface PluralRule
Class PreElement
Interface ProcessingInstruction
Interface ResourcePrototype
Interface Story
Class Artifact<C extends Artifact<C>>
Interface Category
Interface ClientBundle
Interface Accessible (один метод - getAccessibleContext())
Interface Acl (Access Control List (ACL). An Access Control List is a data structure used to guard access to resources.)
Interface Activator
Class AtomicInteger
Class BAD_CONTEXT
Class BindingHolder
Class DefaultValidationEventHandler
Interface DynSequenceOperations
Interface NamingContextExtOperations
Interface SpinnerModel
Class _ServantLocatorStub
...
возникает проблема подыскать имя классу, - имя, которое хоть что-либо бы значило
Страницы