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

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

Проблема в том, что то, что нынче называют ООП, от ООП имеет только термины. По сути современное ООП, это просто набор терминологии, которую утащили из настоящего ООП, куча лозунгов, вокруг этого маркетинга и шумихи + немного синтаксического сахара для старых добрых процедурных методик (модульность, абстрактные типы данных, манипуляции с указателями на функции для диспетчерезации вызовов). Всё.

Отодрали от ООП фасад и прилепили на процедурной язык. Назвали явой, c# или что там нынче модно.

Типы записей (указательные типы) могут переопределяться, обеспечивая таким образом полиморфизм.

У меня такое ощущение иногда складывается, что народ считает ООП тем, где написав имя переменной и поставив точку (или ->, от языка зависит) IDE выдаст список всего того, что с этой переменной можно сделать (список методов и полей, ага). Это считается если не единственным свойством, то основным.

Народ может считать по-разному, но то, что IDE выдаёт после точки всё, что можно сделать с объектом, крайне удобно.

А в BB этого нет, следует ли из этого, что BB крайне не удобен?

У меня такое ощущение иногда складывается, что народ считает ООП тем, где написав имя переменной и поставив точку (или ->, от языка зависит) IDE ...

удобство - это не мода, а возможность ускорить процесс разработки.

ВВ далеко до удобства. По крайней мере, в моём разумении. А удобство - это не мода, а возможность ускорить процесс разработки. По крайней мере, для значительного количества задач.

Представляю себе программера, который не помнит толком, об чём класс, и быстро-быстро выбирает методы

Представляю себе программера, который не помнит толком, об чём класс, и быстро-быстро выбирает методы

Возвращаясь к теме -- ООП не позволяет ускорить процесс разработки для значительного количества задач. Вот исследование на эту тему: http://www.csm.ornl.gov/~v8q/Homepage/P ... ntable.pdf

Существенное ускорение процесса разработки можно достичь правильным выбором инструментария. Языка, библиотек, утилит всевозможных и т.п. Да, это будет не общее решение, это будет частное решение под эту задачу. Серебряной пули нет.

Более того, ООП поощряет частенько ТАКУЮ архитектуру, что в простом процедурном коде "почти без архитектуры" разобраться оказывается намного проще. Напарывался неоднократно на проектах маленьких-среднего размера (100-300 тыс. строк кода).

В чужом коде, действительно тяжелее разобраться с кодами, если всё разделено на классы, нежели просто содержится набор процедур.

Но для модификации собственного кода классы предпочтительней.

Свой код становится чужим через полгода-год (на год забросил проект, вернулся через год). Либо через примерно 50 тысяч строк кода. Кроме того, код обычно пишется командой, так что 90 процентов времени ты разбираешься с чужим кодом. Т.о. вы подтвердили, что ООП провалилось

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

Названия ООПшные, звучит похоже, но ...ростом.