LINUX.ORG.RU

[вброс]Почему объектно-ориентированное программирование провалилось?

 


2

7

http://citforum.ru/gazeta/165/

по линку многабукаф, немного для Ъ:

факт остаётся фактом: сторона, представлявшая объектно-ориентированное программирование, во время открытой дискуссии с противниками под смех зала даже запуталась в своих же концепциях. Люди вспоминают, что у всех создалось стойкое впечатление, что аргументация Lisp’еров была куда убедительней и последовательней, чем сторонников ООП.

Другой крупный критик ООП – это известный специалист по программированию Александр Степанов, который, работая в Bell Labs, участвовал в создании C++ вместе c Бьерном Страуструпом (Bjarne Stroustrup), а впоследствии, уже после приглашения в HP Labs, написал Standard Template Library (STL). Александр Александрович полностью разочаровался в парадигме ООП; в частности, он пишет: “Я уверен, что парадигма ООП методологически неверна. Она начинает с построения классов. Это как если бы математики начинали бы с аксиом. Но реально никто не начинает с аксиом, все начинают с доказательств. Только когда найден набор подходящих доказательств, только тогда на этой основе выводится аксиома. Т.е. в математике вы заканчиваете аксиомой. Тоже самое и с программированием: сначала вы должны начинать развивать алгоритмы, и только в конце этой работы вы приходите к тому, что оказываетесь в состоянии сформулировать четкие и непротиворечивые интерфейсы. Именно из-за этой неразберихи в ООП так популярен рефакторинг – из-за ущербности парадигмы вы просто обречены на переписывание программы, уже в тот самый момент, когда только задумали её спроектировать в ООП-стиле”.

Ричард Столлман (Richard Stallman) также известен своим критическим отношением к ООП, особенно он любит шутить насчет того мифа объектников, что ООП “ускоряет разработку программ”: “Как только ты сказал слово «объект», можешь сразу забыть о модульности”.

Ричард Гэбриел неожиданно сравнивает нынешнюю ситуацию с ООП с провалом эфиродинамики в физике начала 20 века, когда, в сущности, произошла “тихая революция”.

Ответ на: комментарий от siberean

>рефакторинг не так просто делать в си или ассемблере - как в жабе (в каком-нибудь эклипсе).

А почему сишный код рефакторить тяжело? Может мы по разному смысл слова «рефактринг»? Для меня это просто переделка кода с целью перейти от мене удачных архитектурных решений к более удачным. Необязательно для этого пользоваться какими-то возможностями IDE или языка.

На С++ я часто что-то переделываю у себя в коде. На С это так же легко делать.

По поводу «сверху вниз».

Это маркетологи навязали вирусную и неправильную идею, что первоначальные этапы - это базис.

Это мне напоминает ситуацию - если бы говорили что первоначальные этапы жизни ребёнка - это базис. И если он в 3 года сказал что хочет быть принцессой/пожарником - то это уже финально, нужно купить форму пожарника навырост итд, и ничего не будет меняться.

А разве подход к разработке «сверху-вниз» требует, чтобы обязательно к пройденным этапам никогда не возвращались и нельзя было переосмыслять архитектурные решения, сделанные на раннем этапе разработки?

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

Я имею в виду ситуацию - когда сотни файлов. И то когда это жаба написана по жабски, со всеми private, геттерами итд. Жабу очень легко рефакторить благодаря поддержке IDE. сишный даже тот-же эклипс (CDE, когда я делал последний проект на нём) не имел рефакторинга, не говоря про поиски/замещения по файлам в vi. Т.е. приходилось смотреть на ошибки и последовательно перекомпилировать. При больших переделках - как бы немного больший головняк, чем для жабы. Хотя да, и там и там надо иметь и запускать юнит тесты и это облегчит. Я не говорю про ассемблер (на котором не писал 15 лет). Там просто переписывать придётся. Типа ниже уровень - больше артифактов менять при рефакторинге.

разве подход к разработке «сверху-вниз» требует, чтобы обязательно к пройденным этапам никогда не возвращались и нельзя было переосмыслять архитектурные решения, сделанные на раннем этапе разработки?

а зачем он нужен вообще - если его всё равно надо переделывать? Это же себе на голову такая лишняя сущность.

Всё равно я на каждом этапе хочу иметь работоспособную систему, начиная с пустого main, потом юнит тестов, и кончая сотнями файлов. Я расширяю тот main как фрактал. Зачем мне надо планировать, кроме как прикидка в голове - как всё примерно будет устроено, какие фреймвоки будут использованы? Под сверху-вниз обычно пнимают «распилочные» тяжёлые методологии типа SDLC, waterfall, где дизайн каким-то образом делается вперёд имплементации и даже пилота.

anonymous
()
Ответ на: комментарий от anonymous

>а зачем он нужен вообще - если его всё равно надо переделывать? Это же себе на голову такая лишняя сущность.

Можно сделать почти пустой каркас для того, чтобы просто оценить как это будет выглядеть «в целом». А то когда решаешь локальную задачу то «за деревьями не видно леса».

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

надо двигаться от простого к сложному, на каждом этапе имея работоспособную систему (Agile девелопмент, в пределе - экстремальное программирование). В каждую минуту можно тчитаться перед заказчиком, показать ему систему, дать потыркать, спросить: то-ли что ему нужно. Никаких рисков. Поддержание юнит тестов параллельно. Так и растём и вырастаем в большую систему. А начиная с архитекторских программ - получаем жуткую сложность уже вначале, когда ещё алгоритм не работает, и данные не реальные. Такие архитекты обычно линяют в мэнеджмент или нанимают кодеров, и те разгребают всё дерьмо. О, этого я накушался за 15 лет контрактов в больших конторах. Технологии ради технологий - вот почему всё сейчас в такой заднице и сложно.

anonymous
()
Ответ на: комментарий от anonymous

>надо двигаться от простого к сложному, на каждом этапе имея работоспособную систему

Ты так это говоришь, будто это противоречит тому что я говорил. А что мешает быстро набросать каркас с заглушками в виде работающего приложения которое можно показать заказчику, а потом наполнять его деталями и убирать заглушки?

pathfinder ★★★★
()
Ответ на: комментарий от pathfinder

> Ты так это говоришь, будто это противоречит тому что я говорил. А что мешает быстро набросать каркас с заглушками в виде работающего приложения которое можно показать заказчику, а потом наполнять его деталями и убирать заглушки?

значит мы говорим об одном и том-же. Твой каркас с заглушками - это «снизу-вверх», с начала (Agile). «сверху-вниз» - это то чему учат на курсах и даже в университетах (SDLC), я сам даже учил. Это когда год люди не имеют работающую систему, и занимаются дизайном, а потом за 3 месяца перед релизом - надо сделать систему из их нерабтающего дерьма. Потом появляются «неожиданные» проблемы с перформансом и concurrency, на многих процессорах, при реальной нагрузке. Потом всё локают и получают мегатормоза. Плавали, знаем. Это всё SDLC, «сверху-вниз».

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.