Вводное выступление Гая Л. Стила на диспуте по поводу ООП.
Конференция OOPSLA, Сиэтл, 6 ноября 2002г.

Перевод "парного" выступления Ричарда П. Гэбриэла "Объектная парадигма провалилась" расположен здесь.

Оригинал находится по этому адресу.

Очевидно, что объекты преуспели.

Тому есть некоторое практическое подтверждение. Согласно последнему (в 2002 году) опросу североамериканских разработчиков, проведенному Evans Data Corporation, более половины опрошенных используют Java. Около 1/7 опрошенных используют C#. Примерно половина из них также использует Java, так что доля разработчиков, использующих хотя бы один из этих языков, приближается к 3/5. Ожидается, что в следующем году эта доля возрастет. Около 1/5 опрошенных используют Enterprise Java Beans, 2/5 используют COM+, и почти 2/3 используют JavaScript (который, по крайней мере пытается быть объектно-ориентированным).

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

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

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

Фред Брукс писал в девятой главе Мифического человеко-месяца (The Mythical Man-Month):

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

Это было в 1975.

Эрик Реймонд перефразировал замечание Брукса на более современном языке в Соборе и базаре (The Cathedral and the Bazaar):

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

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

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

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

"Умные" структуры данных и глупый код работают гораздо лучше, чем обратный вариант.

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

Язык программирования Scheme был рожден в 1975 году из попытки выразить объектно-ориентированное программирование в тех терминах, которые Джерри Сассман (Gerry Sussman) и я могли понять. В частности, мы хотели переформулировать теорию акторов Карла Хьюита (Carl Hewitt), так сказать, односложными словами. Одним из заключений, к которым мы пришли, было то, что "объект" не обязан быть элементарным понятием языка программирования, можно получить объекты и их поведение, пользуясь лишь ячейками для хранения данных и старыми добрыми лямбда-выражениями. Более того, большинство объектов из теории Хьюита не имело состояния и не менялось после создания, так что для их реализации было достаточно одних лямбда-выражений.

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

Как я отмечал 20 с лишним лет назад в своей работе Lambda: The Ultimate Declarative, в цену использования объектно-ориентированного программирования порой входит сложность добавления нового интерфейсного метода в устоявщийся набор классов (по крайней мере, с помощью обычных текстовых редакторов, используемых как тогда, так и сейчас) - поскольку, несмотря на наследование, придется написать множество индивидуальных объявлений методов, вставить их в каждый существенный класс - в то время как относительно легко можно создать новый класс объекта, новый тип данных. В процедурном программировании все ровно наоборот: там легко добавить новую процедуру, но может оказаться очень сложным и трудоемким добавить новый тип данных в устоявшийся набор процедур, поскольку код должен быть вставлен в каждую существенную процедуру.

Вопрос лишь в том, что в современной практике при поддержке системы происходит чаще - объявление новых универсальных методов, или новых универсальных типов данных? (Под "универсальными" я понимаю вещи, широко используемые во всей системе. Универсальный метод, такой как equal или toString, поддерживается многими типами объектов, а универсальные типы данных, такие как String или Vector, должны поддерживать большинство универсальных методов.) Я утверждаю, что новые универсальные типы объектов появляются чаще, чем новые универсальные методы (это следствие Реймондовского принципа "умных данных, глупого кода"), и это является одной из причин того, что объектно-ориентированное программирование доказало свою успешность: оно уменьшает трудоемкость поддержки программы при работе с адекватными средствами разработки.

Еще одной слабостью процедурного и функционального программирования является то, что их точка зрения предполагает процесс, который трансформирует "входы" в "выходы", они одинаково озабочены корректностью и результатами (и их обоснованиями). Но в то время как мы соединяем миллионы компьютеров, чтобы образовать Internet и World Wide Web, в то время как мы заставляем большие независимые наборы структур взаимодействовать (я говорю о базах данных, автоматических датчиках, мобильных устройствах, и, в первую очередь, людях), в этом высокоинтерактивном, распределенном окружении процедурные и функциональные модели уже провалились, что и стало еще одной причиной того, что объекты стали доминирующей моделью. Сейчас основной интерес представляет поведение, а не завершение процесса. В самом деле, объектно-ориентированное программирование выросло из попыток моделирования поведения взаимодействующих сущностей реального мира - так была рождена Simula.

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

Если вы идеалист, то вы можете быть разочарованным текущим состоянием дел в искусстве объектно-ориентированного программирования. Эволюция объектно-ориентированного программирования еще не завершена (и, возможно, никогда не будет), и я не утверждаю, что Java или C# являются апофеозом объектно-ориентированных языков программирования.

Что касается С++ - что ж, он напоминает мне советскую шутку: "Они делают вид, что платят нам, а мы делаем вид, что работаем". С++ делает вид, что обеспечивает объектно-ориентированную модель данных, программисты на С++ делают вид, что уважают ее, и все делают вид, что этот код будет работать. Реальная модель данных в С++ такая же, как в С, простой двумерный массив битов, 8 раз по 4 миллиарда, и вся синтаксическая сладость С++ принципиально не может прикрыть зияющие дыры в его объектной модели, оставленные оператором приведения типов и неограниченной адресной арифметикой.

Если бы несколько лет назад, когда С++ был на пике популярности, Smalltalk в упадке, а Squeak еще не появился, вы, О достойные оппоненты, пришли бы ко мне и заявили, что объектная парадигма провалился, я, быть может, с этим и согласился. Но сейчас, когда мэйнстримом стала Java, популяризирующая не только объектно-ориентированное программирование, но и смежные технологии, такие как сборка мусора и удаленный вызов методов, и сейчас, когда число инструментов объектно-ориентированного программирования удвоилось с помощью искренней лести (прим. переводчика: от "Имитация - самая искренняя лесть", C.C. Colton) С#, мы можем уверенно утверждать, что объектная парадигма ни в коем случае не провалилась.

Перевод Дмитрия Леонова, август 2004г.

обсудить  |  все отзывы (1)
Выберите оценку 10 (изумительно) 9 (отлично) 8 (хорошо) 7 (неплохо) 6 (средненько) 5 (сойдет) 4 (так себе) 3 (слабо) 2 (плохо) 1 (отвратительно) Вернуться в раздел Перейти к рейтингу Перейти к обсуждению Вернуться к статье	[57106; 18; 7.94]