Шпаргалка по SCJP. Часть вторая

[lair]

Код, написанный по принципу инкапсуляции, содержит private переменные

А в Java правда нет разницы между переменной (variable) и полем (field)?

Наследование — базовая концепция, лежащая в основе полиморфизма, приведения типов, перегрузки и переопределения методов.

Перегрузка методов (method overloading) не имеет ничего общего с наследованием.

А вообще, типичный пример шпаргалки: куча тезисов без внутреннего понимания механизма.

[jstudent]

>А в Java правда нет разницы между переменной (variable) и полем (field)?

Имелись в виду переменные состояния.

>Перегрузка методов (method overloading) не имеет ничего общего с наследованием.

Меня смутил этот момент, но я решил, что Kathy Sierra знать лучше. Скорее всего, он имел ввиду перегрузку наследованного метода.

[lair]

Имелись в виду переменные состояния.

Что такое «переменные состояния» и чем они отличаются от полей?

Меня смутил этот момент, но я решил, что Kathy Sierra знать лучше.

Своей головой думать полезно. Особенно тогда, когда вы пишете пост на хабре от своего имени.

[jstudent]

>Что такое «переменные состояния» и чем они отличаются от полей?
Ничем, синоним.

>Особенно тогда, когда вы пишете пост на хабре от своего имени.
Указал источник. До этого в первой части было указано происхождение поста.

[lair]

И что вам тогда мешает писать «общепринятое» слово «поле», чтобы не было дурацких вопросов?

[rachiu]

«Код, написанный по принципу инкапсуляции, содержит private переменные, доступ к которым осуществляется через методы (setVarName и getVarName).» — это не инкапсуляция, а полное раскрытие переменной. Инкапсуляция — это нечто большее и другое, но с пониманием этоо бывает куча проблем даже у авторов экзаменов.

[mayorovp]

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

[mayorovp]

Извиняюсь, это был ответ на комментарий выше

[lair]

Нет, это не необходимое условие инкапсуляции. К этим переменным вообще может не быть доступа извне класса.

[mayorovp]

Просто фраза недостаточно формализована. Я ее читаю примерно так:
Код, написанный по принципу инкапсуляции, МОЖЕТ содержать поля, которые ОБЯЗАНЫ быть приватными, а доступ МОЖЕТ осуществляться ТОЛЬКО через методы (setVarName и getVarName).
Это действительно необходимое условие инкапсуляции.

Впрочем, можно прочитать и как
Код, написанный по принципу инкапсуляции, ОБЯЗАН содержать приватные поля, доступ к которым осуществляется через методы (setVarName и getVarName).
Тогда это будет чушью.

[lair]

По-моему, достаточно написать, что в коде, ориентированном на инкапсуляцию, нет публичных полей.

Всё.

[valkiriy]

Мне одному кажется, что переписывание глав книг на хабр это совсем не то, ради чего мы все тут собрались?

Автор, добавьте хотя бы тег перевод к статье.

[Lendon]

Я бы еще добавил, что вызов конструктора супер-класса должен быть первой строкой в конструкторе.

[lair]

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

[Lendon]

Что вы имеете ввиду под «поддержать это синтаксисом»? Чем плоха ошибка компиляции? Как по мне этого достаточно.

[lair]

Что вы имеете ввиду под «поддержать это синтаксисом»?

public Apple(): super() {
}

Чем плоха ошибка компиляции?

А в Java помещение super() в строчку, отличную от первой, дает ошибку компиляции?

[Lendon]

Конечно. Я думаю перед тем как спрашивать такие вещи лучше было бы самому попробовать :)

[lair]

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

[zubrabubra]

При переопределении методы
…
Должны иметь неизменный тип возвращаемого значения.

java.dzone.com/articles/covariant-return-type-abyssal — враки :)
если честно не совсем понимаю смысла в цикле статей, так как вся изложенная информация есть в JLS, а также книгах с информацией для сдачи SCJP.