Java или C++ испытывают недостаток в каких-либо функциях OO?

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

Есть еще один способ думать об объектно-ориентированном программировании, который отличается от системы на основе классов в Java и C++. Программирование на основе прототипов используется в JavaScript. Если вы хотите посмотреть на всю гамму стилей ООП, то, вероятно, стоит заглянуть сюда: http://en.wikipedia.org/wiki/Prototype-based_programming

Большинство интерпретируемых языков соответствуют требованиям позднего связывания. В Perl вы можете извлечь код из таблицы базы данных, передать его интерпретатору, а затем создать экземпляры объектов нового класса, который вы только что ввели в программу.

Полностью ли Python соответствует определению ООП, данному Кей? Я недостаточно работал с Python, чтобы быть уверенным. Я подозреваю, что нет, поскольку у Python есть «собственные типы», которые не являются объектами.

В Java нет множественного наследования, но некоторые могут сказать, что это скорее благо, поскольку требует от пользователей думать о правильной архитектуре. Вы можете использовать интерфейсы и абстрактные классы, чтобы обойти это.

Множественное наследование подвергалось критике за следующие проблемы, которые оно вызывает в некоторых языках, в частности в C ++:

• Семантическая неоднозначность часто резюмируется как проблема ромба .
• Невозможность явного наследования несколько раз от одного класса
• Порядок наследования, изменяющий семантику класса

В словами Алана Кея , изобретателя термина «объектная ориентация»:

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

C ++ явно не соответствует критерию «крайнего позднего связывания», а Java и C ++ не удовлетворяют критерию «обмена сообщениями» из-за их жесткой структуры классов / методов. Насколько я понимаю, концепция Кея рассматривает методы с определенным именем и подписью как удобный способ реализации обработчиков сообщений, но ни в коем случае не единственный.

Другие интересные утверждения из того же электронного письма:

Мне не понравилось, как Simula I или Simula 67 выполняли наследование [...] Поэтому я решил не учитывать наследование как встроенная функция, пока я не разобрался лучше.

и

Термин «полиморфизм» был введен намного позже (я думаю, Питером Вегнером) , и он не совсем верен, поскольку на самом деле происходит из номенклатуры функций , и мне нужно было немного больше, чем просто функции.

Java: примитивные типы не являются объектами.

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

В C ++, поскольку у вас есть неконтролируемые указатели, один плохо написанный объект может буквально что угодно делать с другим. Это означает, что инкапсуляция нарушена и ошибки трудно найти.

В Java нет этой проблемы, но ей не хватает базовой константности.Это не строго объектно-ориентированная теоретическая функция, но возможность объявить, что метод доступен только для чтения или что объект доступен только для чтения, является фантастическим средством повышения надежности в C ++, чего нет в Java.

Наконец, механизм шаблонов java - бледная имитация C ++. Невозможность параметризации классов - огромная потеря для Java.

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

И Java, и C ++ допускают процедурное программирование. Для некоторых это можно считать минусом.