Действительно ли Java 100% объектно-ориентирован? [закрытый]

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

Это один из тех вопросов, который действительно имеет значение только в академическом смысле. Ruby оптимизирован для обработки целых, длинных и т. Д. Как примитивов, когда это возможно. Java только что сделала это явным. Если бы в Java примитивы были объектами, были бы классы IntPrimitive, LongPrimitive и т. Д. (Под любым именем). который, скорее всего, будет окончательным без специальных методов (например, без IntPrimitive.factorial). Это означало бы, что для большинства целей они будут примитивами.

Нет. Например, Javascript - это.

На чем будут записаны эти классы Integer, Long и Boolean? Как бы вы написали ArrayList или HashMap без примитивных массивов?

Одна из причин, по которой Java явно не может избавиться от не объектных примитивов ( int и т. Д.), Заключается в том, что она не поддерживает собственные элементы данных. Представьте себе:

class int extends object
{
    // need some data member here.  but what type?
    public native int();
    public native int plus(int x);
    // several more non-mutating methods
};

Поразмыслив, мы знаем, что Java поддерживает внутренние данные для каждого объекта (блокировки и т. Д.). Возможно, мы могли бы определить класс int без элементов данных, но с собственными методами, которые манипулируют этими внутренними данными.

Остающиеся проблемы: Константы - но с ними можно справиться аналогично строкам. Операторы - это просто синтаксический сахар и + , и они будут отображены методом plus во время компиляции, хотя мы должны быть осторожны, чтобы int.plus (float) возвращает float , как и float.plus (int) и т. д.

В конечном счете, я думаю, что оправданием примитивов является эффективность:

Итак, можем ли мы рассматривать Java как 100% объект ориентированный язык?

Нет.

Другой вопрос: почему java не проектировать примитивные типы данных как объект способ?

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

Java не является 100% объектно-ориентированным. Java может приближаться к 99% объектно-ориентированному программированию (подумайте об автобоксе, Scala). Я бы сказал, что Java сейчас на 87% объектно ориентирована.

Почему Java не создает примитивные данные типы как объектный способ?

Еще в 90-е были причины для повышения производительности, и в то же время Java остается обратно совместимой. Поэтому они не могут их вытащить.

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

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

Тем не менее, в Java есть объекты, которые обертывают вокруг примитивов, таких как Integer , Boolean , Character и т. д. Причиной наличия примитивов, вероятно, является причина, указанная в ответе Питера - когда в середине 90-х годов была представлена ​​Java, память в системах была в основном в двузначных мегабайтах, поэтому наличие каждого значения как объекта было большими накладными расходами .

(Большой, конечно, относительный. Я не могу вспомнить точные числа, но накладные расходы на объект составляли около 50-100 байт памяти. Определенно больше, чем минимум в несколько байтов, требуемых для примитивных значений)

Сегодня на многих рабочих столах с несколькими гигабайтами памяти накладные расходы на объекты не представляют большой проблемы.

Сегодня, когда многие рабочие столы имеют несколько гигабайт памяти, накладные расходы на объекты не представляют большой проблемы.

Сегодня, когда многие рабочие столы имеют несколько гигабайт памяти, накладные расходы на объекты не представляют большой проблемы.

Чтобы достичь истинного 100% объектно-ориентированного подхода, подумайте, например, о Smalltalk, где все является объектом, включая сам компилятор, и даже операторы if : ifTrue: - это сообщение, отправленное логическому объекту с параметром блока кода.

«Почему java не проектирует примитивные типы данных как объектный способ?»

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

Я бы сказал, что полноцветные языки - это такие языки, в которых их элементы (классы, методы) доступны в виде объектов для работы.

Из этого POV, Java не является полностью ООП-языком, а JavaScript является (неважно, имеет ли он примитивы).

Java не полностью ориентирован на объект. Я бы рассмотрел SmallTalk и Eiffel самых популярных полностью объектных ориентированных языков.

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

1.class

, и он вернет класс 1 (FIXNUM, который в основном является числом). Вы не можете сделать это в Java.

Проблема в том, что объектно-ориентированная на самом деле не очень хорошо определена и может много значить. Эта статья объясняет проблему более подробно: http://www.paulgraham.com/reesoo.html

Также Алан Кей (изобретатель Smalltalk и автор(?) термина "объектно-ориентированный") известен тем, что не имел в виду Си++, когда думал об ООП. Поэтому я думаю, что это может относиться и к Java.

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

Согласно Concepts in Programming Languages book, существует нечто, называемое Ingalls test, предложенное Dan Ingalls лидером группы Smalltalk. То есть:

Можете ли вы определить новый вид целого числа, помещайте ваши новые целые числа в прямоугольники (которые уже являются частью окна система), попросите систему очернить прямоугольник, и все ли работает?

И опять же, согласно книге, Smalltalk проходит этот тест, а C++ и Java - нет. К сожалению, книга не доступна онлайн, но вот некоторые поддерживающие слайды (слайд 33 отвечает на ваш вопрос).

Я полагаю, что вам нужно будет использовать [GroupIgnore] в перечислении и создать второе свойство, возвращающее целое значение:

[XmlRoot("GeoCoordinate")]
public class GeoCoordinate
{
    public enum AccuracyLevel
    {
        Unknown = 0,
        Country = 1,
        Region = 2,
        SubRegion = 3,
        Town = 4,
        PostalCode = 5,
        Street = 6,
        Intersection = 7,
        Address = 8,
        Premise = 9
    }

    private AccuracyLevel _accuracy;

    // ... more members


    [XmlIgnore]
    public AccuracyLevel Accuracy
    {
        get { return _accuracy; } 
        set { _accuracy = value;}
    }

    [XmlElement("AccuracyLevel")]
    public int AccuracyLevelInt
    {
        get {return (int) AccuracyLevel;}
        set {AccuracyLevel = (AccuracyLevel) value;}
    }
}

Обратите внимание, что [Serializable] не используется XML-сериализатором.

Также обратите внимание на то, что свойство AlignLeign Int , вероятно, реализовано неправильно. Я изучаю это сейчас.

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

Нет, поскольку он имеет типы данных, которые не являются объектами (например, int и байт ). Я считаю, что Smalltalk действительно ориентирован на объекты, но у меня есть лишь небольшой опыт работы с этим языком (около двух месяцев, примерно пять лет назад).

Я также слышал заявления от толпы Руби, но у меня есть нулевой опыт с этим языком.

Это, конечно, с использованием определения «истинно ОО», означающего, что у него есть только объекты и нет других типов. Другие могут не согласиться с этим определением.

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

Следующий код хорошо работает:

#!/usr/bin/python
i = 7
print id(i)
print type(i)
print i.__str__()

вывод:

6701648
<type 'int'>
7

, так что даже базовые целые являются здесь объектами.