Эх... скучно... вот еще одна статья, она, правда, не опровергает первую, но взгдял с другой стороны тоже стоит прочитать
-----------
Объектная парадигма не провалилась
Гай Л. Стил, перевод - Дмитрий Леонов
Опубликовано: dl, 23.08.04 22:15
Вводное выступление Гая Л. Стила на диспуте по поводу ООП.
Конференция 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) С#,
мы можем уверенно утверждать, что объектная парадигма ни в коем случае не провалилась.
Из последней статьи:
...это является одной из причин того, что объектно-ориентированное программирование доказало свою успешность: оно уменьшает трудоемкость поддержки программы
при работе с адекватными средствами разработки.
Это очевидная глупость.Имхо.
Трудоёмкость поддержки программы возрастает.
Уменьшается трудоемкость разработки программы. За счет перекладывания работы по составлению корректного кода на интерфейсы объектов. При этом объект вынужден страховать ленивого и неумелого разработчика, что сказывается не лучшим образом на всех его параметрах. И в конечном итоге на параметрах кода.
К чему это ведёт? На мой взгляд, к вымиранию прикладного программирования и появлению класса "пользователей компилятора", не способных составлять код. А действительно программирование останется только системщикам из MicroSoft.
Artyom, до меня дошла весть о твоем появлении и я тебя приветствую! Похоже, ты переставил таки свою Винду и жаждешь продолжить наш тест. И это радует. Ну как, будем сортировать? Если да, то для начала подскажите мне, как мне этот эээ... не знаю как и назвать, (ехе-шник что-ли?) запускать. Т.е. ту программу, которую ты сделаешь для сортировки. Ибо, (только без обид) нет доверия к результату 1,6. Хочу чтобы тестировалось и у меня тоже, интересно посмотреть.
И второе: Раз ты предложил такие условия, (напомню: сортировать 100000 структур с тремя полями: два 16-битных, и одно строковое произвольной длины от 0 до 2 Гб), то пожалуйста, напиши программу, которая сможет в обозримом будущем составить такой тестовый файл для сортировки. Я не возьмусь такой файл делать. Ибо я не знаю, как делать файлы размером с сотню тысяч гигабайт. Раз ты предложил такие условия, то возможно, ты знаешь, как такие файлы составляются. Тебе и карты в руки. ))
И ещё: как быть с тем, что один такой файл не влезет даже на тысячу среднестатистических винтов? Я не знаю ((
В общем, я к твоим услугам
P.S. Если непонятно, откуда взялась такая цифра (100000 гигабайт), то поясню: средняя длина строки (0 + 2Гб)/2 = 1 Гб. И таких строк 100000. Умножаем 100000 на 1Гб и имеем 107374182400000 байт. Я даже не знаю, как такие числа произносятся...
P.P.S. Возможно, ты погорячился, ничего страшного, можно придумать более реальные условия теста.
P.P.P.S. Когда некто в разных топиках оставляет сообщения наподобие таких: "Иди и почитай книги по ВБ, прежде чем вылазить в форум", или "ты заслужил премию ламерсок", или "ты действуешь\предлагаешь по ламерски", то не грех разочек показать этому человеку, что он тоже может оказаться в положении, в которое ставит других. Пусть примерит на себя. Я понимаю, что у тебя до некоторой степени неприятие ко мне. И поэтому ты будешь солидарен с любым, кто испытывает такое же. Но походи по недавним топикам, и возможно ты поймешь меня.
Мне всё равно, сколько будет длина Name, я с ней все равно работать не буду, только с указателем на начало строки. А это всего 4 байта.
О CrLf: не вижу ограничений на присутствие\отсутствие этого. Пусть будет. Это ведь такой же строковый элемент, как и другие.
Единственно что поле Name должно завершаться нулём, если длина не фиксирована. Это чтобы не принять за продолжение строки соседнее цифровое поле.
Я тут пытался как-то этот Net Framework установить, так у меня потребовали сервис-пак 1, придётся что-ли и его устанавливать? Или можно как-нибудь обмануть это? Без сервис-пака?
А ты не путаешь .Net Framework и VS .NET?
Все версии .NET Framework (от 1.0 до 2.0 beta) устанавливаются без
каких-либо сервиспаов, на Windows 98, Me, NT, 2k, XP, 2k3, Longhorn.
А SP1 может требовать только VS .NET 2005.
Да, попутал, извиняюсь. Сейчас вроде установил, не знаю...
Павел, может кинешь мне на мыло какой-нибудь файлик, чтоб проверить работает это или нет? Ну там простейшую какую нибудь программку?
Извините меня конечно, но тут на майл пришло письмо, мол в вашу тему ответили, ну открыл, думаю: епт, больные чтоли? Нет серьезно, вы нормальные нет? На второй старнице сказал чтоб тему удалили, что мол нет смысла бозарить тут, а тут смарю, 10ть страниц, ну блин круто
Просто интересно стало че могли сюда запостить за полгода а тут тема живет и процветает :D
Вот только Artyom, пригласил меня в эту давно заброшеную тему а сам опять куда-то сквозанул.
Может он так прикалывается? Как дети: позвонят в дверь, и сваливать, пока никто не вышел )) Зачем было приглашать???
Artyom, если ты пригласил меня в эту тему, то будь добр, появись, а то действительно получается кроме как в грудь стучать ничего более не можешь... И за честь .NET вступиться некому (( Я тебя уже двое суток жду ((
Или может с Павлом поэкспериментируем, хотя может у него со временем не густо, админские полномочия и т.д.