В Java НЕТ Generics!
В отличие от шаблонов C#, шаблоны Java не поддерживаются средой исполнения — компилятор просто создаёт байт-код, в котором никаких шаблонов уже нет. Реализация шаблонов в Java принципиально отличается от реализации аналогичных механизмов в C++: компилятор не порождает для каждого случая использования шаблона отдельный вариант класса или метода-шаблона, а просто создаёт одну реализацию байт-кода, содержащую необходимые проверки и преобразования типов. Это приводит к ряду ограничений использования шаблонов в программах на Java.
Зачем это было сделано — очевидно. Мне лишь не нравится реализация где предок знает о потомках.
Смотрите мое предложение чуть ниже. или реализацию Int32 в C# msdn.microsoft.com/en-us/library/system.int32.aspx
, где (на мое удивление) используется тот же принцип, что и предложенный мной ниже — т.е. каждому числу навязывается набор интерфейсов для возможностей конвертации в другие форматы.
IMNSHO все должно было бы работать иначе.
Должны были существовать интерфейсы Float/Double/Imteger/etcExportable, которые бы навязывались классу -реализации Number. Т.е. например:
class Integer extends Number implements FloatExportable, DoubleExportable, ByteExportable,…
«С System связано еще несколько странностей — например out и in поля класса — final. Но в то же время есть методы setOut и setIn.»
Не так красиво как хотелось бы, но вполне разумно.
Ни in, ни out не сэтятся напрямую. Их установка происходит в native методах, которым плевать на идентификатор final.
Т.е. получается что Вы можете использовать публичные in и out, но можете их изменить только через сэттеры. А в сеттерах (прикрученных много позже появления System.out) проверяются разрешения на установку ввода-вывода.
p.s. Да, наличие публичных геттеров и приватных полей было бы красивее.
То что есть сейчас — всего лишь одни из самых адекватных костылей к древнему, но широко используемому коду.
Тот факт что switch работает только со строками, возможно, основан на следующем:
Switch по сути своей идентичен последовательности if — else, за двумя исключениями:
— более компактный синтаксис
— switch быстрее(как минимум был раньше) за счет ограниченной поддержки типов. Возможно работа со стрингАми захардкожена таким образом что equals для стринга проверяется быстрее чем equals для Object.
Еще один интересный момент.
Класс Number изначально знает обо всех своих детях объявляя у себя методы а-ля:
public abstract double doubleValue();
ООП переворачивается в гробу ;)
C Serializable все несколько забавнее.
writeObject() и readObject() предполагаются быть приватными, дабы никто кроме jvm (и соответственно рефлекшена) не имел к ним доступа.
Но как объявить приватные члены интерфейса? Никак…
Именно поэтому пришлось организовать подобную магию.
Можно было бы применить абстрактный класс, но
private abstract void writeObject(); не является допустимой конструкцией также
Если вы (компания) просто сборщик, то так и стоит писать.
Не нужно заставлять людей искать инновации, там где есть только компоновка чужих деталей и ПО.
Это ведь зарплата одного разработчика на 2.5 месяца всего лишь.
И это с учетом того что не платятся налоги и не нужно содержать офис. С налогами и прочим — это зарплата на 1-1.5 месяца максимум.
Вполне разумный аванс.
Тогда они не будут знать к чему стремиться ;)
А так —
СЕО: Слыш у меня в майбахе еще такая штуковина есть *******
ГЛАВИНЖЕНЕР: Записал под номером 198843872904, сделаем к 2634-му году, наверное…
СЕО: А пораньше никак?
ГЛАВИНЖЕНЕР: Ну если подвинуть все пункты про кляньчинье денег у государства — можем сделать завтра!
В отличие от шаблонов C#, шаблоны Java не поддерживаются средой исполнения — компилятор просто создаёт байт-код, в котором никаких шаблонов уже нет. Реализация шаблонов в Java принципиально отличается от реализации аналогичных механизмов в C++: компилятор не порождает для каждого случая использования шаблона отдельный вариант класса или метода-шаблона, а просто создаёт одну реализацию байт-кода, содержащую необходимые проверки и преобразования типов. Это приводит к ряду ограничений использования шаблонов в программах на Java.
на всякий случай:
Integer — класс-реализация Number, и я предложил другой вариант его описания
Смотрите мое предложение чуть ниже. или реализацию Int32 в C#
msdn.microsoft.com/en-us/library/system.int32.aspx
, где (на мое удивление) используется тот же принцип, что и предложенный мной ниже — т.е. каждому числу навязывается набор интерфейсов для возможностей конвертации в другие форматы.
Должны были существовать интерфейсы Float/Double/Imteger/etcExportable, которые бы навязывались классу -реализации Number. Т.е. например:
class Integer extends Number implements FloatExportable, DoubleExportable, ByteExportable,…
Так было бы гораздо более по-ООПшному, согласны?
Не так красиво как хотелось бы, но вполне разумно.
Ни in, ни out не сэтятся напрямую. Их установка происходит в native методах, которым плевать на идентификатор final.
Т.е. получается что Вы можете использовать публичные in и out, но можете их изменить только через сэттеры. А в сеттерах (прикрученных много позже появления System.out) проверяются разрешения на установку ввода-вывода.
p.s. Да, наличие публичных геттеров и приватных полей было бы красивее.
То что есть сейчас — всего лишь одни из самых адекватных костылей к древнему, но широко используемому коду.
" К счастью, в 7-й java это исправили. Не понятно только — зачем так долго ждали?"
Очень интересно как исправили!
Хотите как в CriteriaAPI?
Switch по сути своей идентичен последовательности if — else, за двумя исключениями:
— более компактный синтаксис
— switch быстрее(как минимум был раньше) за счет ограниченной поддержки типов. Возможно работа со стрингАми захардкожена таким образом что equals для стринга проверяется быстрее чем equals для Object.
p.s. Это предположение
Он знает лишь об их общих чертах.
getValue() — общая черта
getInteger() — специфичная, основанная на том что один из наследников работает с Integer
Класс Number изначально знает обо всех своих детях объявляя у себя методы а-ля:
public abstract double doubleValue();
ООП переворачивается в гробу ;)
writeObject() и readObject() предполагаются быть приватными, дабы никто кроме jvm (и соответственно рефлекшена) не имел к ним доступа.
Но как объявить приватные члены интерфейса? Никак…
Именно поэтому пришлось организовать подобную магию.
Можно было бы применить абстрактный класс, но
private abstract void writeObject(); не является допустимой конструкцией также
Не нужно заставлять людей искать инновации, там где есть только компоновка чужих деталей и ПО.
Это оплата человеко-месяцев. Кол-во проектов значения не имеет.
P.s. У нас тоже еще используется xml маппинг — будь он проклят…
И это с учетом того что не платятся налоги и не нужно содержать офис. С налогами и прочим — это зарплата на 1-1.5 месяца максимум.
Вполне разумный аванс.
А так —
СЕО: Слыш у меня в майбахе еще такая штуковина есть *******
ГЛАВИНЖЕНЕР: Записал под номером 198843872904, сделаем к 2634-му году, наверное…
СЕО: А пораньше никак?
ГЛАВИНЖЕНЕР: Ну если подвинуть все пункты про кляньчинье денег у государства — можем сделать завтра!