Комментарии 46
Поэтому а)менять спецификатор доступа не рекомендуется б)в C# был введен модификатор override, который вводит ясность в то, переопределили ли вы что-нибудь, или нет )
А вообще вам советую пользоваться аннотацией @Override, если есть возможность — компилятор сразу подскажет, что не так.
А вообще вам советую пользоваться аннотацией @Override, если есть возможность — компилятор сразу подскажет, что не так.
default видимость методов — зло.
Вся сложность этих задачек в тесте, это отвратительный стиль, в которых они написаны. Код абсолютно нечитаем.
«Дайте мне другой глобус!»
Вообще-то это перевод, так что код не мой. А что именно не так?
Я про тест по ссылке, безусловно.
1. Коментарии внутри кода, его деформируют и очень мешают.
2. Отступы нам не нужны принципиально.
3. Методы написаны в одну строчку, даже после фигурных скобок нету переносов строки.
Хороший код практически не меняется от процедуры форматирования в Eclipse/Idea. Этот же код меняется кардинально. С учетом ограничения по времени и отсутсвия подсветки, это критично.
1. Коментарии внутри кода, его деформируют и очень мешают.
2. Отступы нам не нужны принципиально.
3. Методы написаны в одну строчку, даже после фигурных скобок нету переносов строки.
Хороший код практически не меняется от процедуры форматирования в Eclipse/Idea. Этот же код меняется кардинально. С учетом ограничения по времени и отсутсвия подсветки, это критично.
Гхм… Странные вещи говорите. Фактически вы утверждаете, что единственный правильный способ форматированяи — эклипсовый по-умолчанию? С фигли? Если мне нравится другой стиль?
Это зависит от настроек эеклипса. Кто мешает его настроить так, как в примерах?
Это зависит от настроек эеклипса. Кто мешает его настроить так, как в примерах?
Я Java Code Convention намекаю. Банально вопрос культуры и уместности. Дома на тетрадке можно писать коряво и неграмотно и в своей уникальной системе счисления. Если же это некий публичный труд, то его стоит делать в общепринятой манере. По крайней мере, чтобы это читалось.
Пользуйтесь другим стилем на здоровье, раз нравится, только в тесте нет никакого стиля. Около минуты ушло лишь на то, чтоб прочесть код, в то время как с форматированием и правильными комментариями ушло бы не больше 10 секунд.
Да, можно было бы добавить интуитивности в коде, и сделать члены и объекты определенного класса одного цвета :)
а то глаза летают в этих ц1/2/3 %)
а так c1 и m() — красного
c2 и m() — зеленого
и т.д.
а то глаза летают в этих ц1/2/3 %)
а так c1 и m() — красного
c2 и m() — зеленого
и т.д.
НЛО прилетело и опубликовало эту надпись здесь
Жесть какая )))
Лишний повод перейти на .NET :)
Лишний повод перейти на .NET :)
лишний повод понять что значат спецификаторы доступа (:
Не думаю. Всем нормальным языкам достаточно private, protected и public.
С точки зрения техологичности и удобности как языка — Яве до C# еще лет 5 расти — вот вам явный пример. Но увы, по количеству готовых решений и столь всеми любимой кроссплатформенности — С#-у до Явы столько же
удобность языка весьма субъективная оценка
Ява, как язык, действительно очень отстаёт по возможностям от того же C#. Но на этой платформе есть другие языки, которые позволяют использовать тонны существующих библиотек, и при этом дают много полезных возможностей. Сам пишу большую часть кода на groovy, для явы оставляю в основном математику и всякие вспомогательные библиотечки.
модификаторы…
Ужас. Пишу на Java уже пол года (до этого писал на C++ несколько лет) и радуюсь. А тут… Прямо не знаю, что думать.
НЛО прилетело и опубликовало эту надпись здесь
Да, ужас заключается в том, что такая спецификация не соответствует моим личным представлениям (которые сформировались за годы коммерческой разработки на C++) о том, как должен работать объектно-ориентированный код. По моим представлениям такие примеры вообще не должны компилироваться.
Ну а писать на Java я всё-равно не перестану. Слишком велики бенифиты, даже несмотря на такие досадные, на мой взгляд, ляпы в спецификации.
Ну а писать на Java я всё-равно не перестану. Слишком велики бенифиты, даже несмотря на такие досадные, на мой взгляд, ляпы в спецификации.
А на c++ вас не пугали множественные наследования ?:)
А тут и думать нечего, такой код в реально жизни никогда не встретится кроме собеседований.
НЛО прилетело и опубликовало эту надпись здесь
Тест прошел, достаточно лишь помнить, что в Java все методы виртуальные и что /*default*/ — это не что иное, как package protected, т.е. метод будет доступен всем классам данного пакета.
Думаю для начало надо прочитать правила overriding:
1)The argument list must exactly match that of the overridden method. If they don't match, you can end up with an overloaded method you didn't intend.
2)The return type must be the same as, or a subtype of, the return type declared in the original overridden method in the superclass.
3)The access level CAN'T BE MORE RESTRICTIVE than the overridden method's.
4)The access level CAN be less restrictive than that of the overridden method.
5)Instance methods can be overridden only if they are inherited by the subclass. A subclass within the same package as the instance's superclass can override any superclass method that is not marked private or final. A subclass in a different package can override only those non-final methods marked public or protected (since protected methods are inherited by the subclass).
6)The overriding method CAN throw any unchecked (runtime) exception, regardless of whether the overridden method declares the exception.
7)The overriding method must NOT throw checked exceptions that are new or broader than those declared by the overridden method. For example, a method that declares a FileNotFoundException cannot be overridden by a
method that declares a SQLException, Exception, or any other non-runtime exception unless it's a subclass of FileNotFoundException.
8)The overriding method can throw narrower or fewer exceptions. Just because an overridden method «takes risks» doesn't mean that the overriding subclass' exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares.
9)You cannot override a method marked final.
10)You cannot override a method marked static.
11)If a method can't be inherited, you cannot override it. Remember that overriding implies that you're reimplementing a method you inherited!
И на последок еще одна интересный пример со взрывом мозга:):
Integer i1 = 1000;
Integer i2 = 1000;
if(i1 != i2) System.out.println(«different objects i1i2»);
if(i1.equals(i2)) System.out.println(«meaningfully equal i1 equals i2»);
Integer i3 = 10;
Integer i4 = 10;
if(i3 == i4) System.out.println(«same object i3 == i4»);
if(i3.equals(i4)) System.out.println(«meaningfully equal i3 equals i4»);
Пример выведит:
different objects i1i2
meaningfully equal i1 equals i2
same object i3 == i4
meaningfully equal i3 equals i4
1)The argument list must exactly match that of the overridden method. If they don't match, you can end up with an overloaded method you didn't intend.
2)The return type must be the same as, or a subtype of, the return type declared in the original overridden method in the superclass.
3)The access level CAN'T BE MORE RESTRICTIVE than the overridden method's.
4)The access level CAN be less restrictive than that of the overridden method.
5)Instance methods can be overridden only if they are inherited by the subclass. A subclass within the same package as the instance's superclass can override any superclass method that is not marked private or final. A subclass in a different package can override only those non-final methods marked public or protected (since protected methods are inherited by the subclass).
6)The overriding method CAN throw any unchecked (runtime) exception, regardless of whether the overridden method declares the exception.
7)The overriding method must NOT throw checked exceptions that are new or broader than those declared by the overridden method. For example, a method that declares a FileNotFoundException cannot be overridden by a
method that declares a SQLException, Exception, or any other non-runtime exception unless it's a subclass of FileNotFoundException.
8)The overriding method can throw narrower or fewer exceptions. Just because an overridden method «takes risks» doesn't mean that the overriding subclass' exception takes the same risks. Bottom line: an overriding method doesn't have to declare any exceptions that it will never throw, regardless of what the overridden method declares.
9)You cannot override a method marked final.
10)You cannot override a method marked static.
11)If a method can't be inherited, you cannot override it. Remember that overriding implies that you're reimplementing a method you inherited!
И на последок еще одна интересный пример со взрывом мозга:):
Integer i1 = 1000;
Integer i2 = 1000;
if(i1 != i2) System.out.println(«different objects i1i2»);
if(i1.equals(i2)) System.out.println(«meaningfully equal i1 equals i2»);
Integer i3 = 10;
Integer i4 = 10;
if(i3 == i4) System.out.println(«same object i3 == i4»);
if(i3.equals(i4)) System.out.println(«meaningfully equal i3 equals i4»);
Пример выведит:
different objects i1i2
meaningfully equal i1 equals i2
same object i3 == i4
meaningfully equal i3 equals i4
Да, примерчик действительно мозги взрывает!)
Единственное, что приходит в голову — видимо jvm создаёт глобальные экземпляры Integer от -128 до 127, и из-за этого ссылки i3 и i4 действительно указывают на один и тот же глобальный объект. Надо будет на эту тему доки полистать — может ещё что интересное откопается.
А насчёт перегрузки методов, мне она кажется вполне логичной — перегружается только то, что видно классу-потомку, всё остальное переопределяется.
Единственное, что приходит в голову — видимо jvm создаёт глобальные экземпляры Integer от -128 до 127, и из-за этого ссылки i3 и i4 действительно указывают на один и тот же глобальный объект. Надо будет на эту тему доки полистать — может ещё что интересное откопается.
А насчёт перегрузки методов, мне она кажется вполне логичной — перегружается только то, что видно классу-потомку, всё остальное переопределяется.
Про Integer я уже где-то читал, так хоть и не помнил точно, но догадался, что тут подвох и ответил правильно :) Но действительно, взрыв мозга при первом разе обеспечен
Это называется autoboxing и трактуется многими компиляторами, как warning.
В данном примере i3 — объект, а не примитив.
Так что
Integer i3 = 10;
равносильно
Integer i3 = Integer.valueOf(10);
и как уже заметили, в этом случае значения от -128 до 127 берутся из кэша объектов, поэтому ссылки будут одинаковые.
В данном примере i3 — объект, а не примитив.
Так что
Integer i3 = 10;
равносильно
Integer i3 = Integer.valueOf(10);
и как уже заметили, в этом случае значения от -128 до 127 берутся из кэша объектов, поэтому ссылки будут одинаковые.
Есть тонны статей, об ущербности наследования и переопределения методов(J.Bloch — Effective Java — Item 16: Favor composition over inheritance). Если у вас в системе появляется такая цепочка наследования, то ошибка в архитектуре скорее. А если интересно, то в пазлах Блоха много таких примерчиков www.javapuzzlers.com/. Только в реальном программировании они редко встречаются.
Про модификаторы доступа советую почитать в книге для подготовки к SCJP 6. Там очень понятно все описано, наверно, лучше нигде не встречал.
ipicture.ru/Gallery/Viewfull/20200390.html
ipicture.ru/Gallery/Viewfull/20200390.html
Прошёл тест на логике. Ни разу ни явист. ))
Все 4 вопроса правильно!
Все 4 вопроса правильно!
На самом деле все достаточно просто (хотя соглашусь с тем, что такой код — плохая практика).
Для переопределения метода необходимо, чтобы класс имел доступ к переопределяемому методу (не обязательно у непосредственного родителя) /а так же чтобы порядок и типы параметров совпадали, видимость не сужалась а исключения не расширялись/.
В противном случае (если родительский метод вне видимости) имеет место обычное определение метода.
Капитан О
Для переопределения метода необходимо, чтобы класс имел доступ к переопределяемому методу (не обязательно у непосредственного родителя) /а так же чтобы порядок и типы параметров совпадали, видимость не сужалась а исключения не расширялись/.
В противном случае (если родительский метод вне видимости) имеет место обычное определение метода.
Капитан О
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Абсолютная загадка наследования в Java