Комментарии 19
Код, написанный по принципу инкапсуляции, содержит private переменные
А в Java правда нет разницы между переменной (variable) и полем (field)?
Наследование — базовая концепция, лежащая в основе полиморфизма, приведения типов, перегрузки и переопределения методов.
Перегрузка методов (method overloading) не имеет ничего общего с наследованием.
А вообще, типичный пример шпаргалки: куча тезисов без внутреннего понимания механизма.
>А в Java правда нет разницы между переменной (variable) и полем (field)?
Имелись в виду переменные состояния.
>Перегрузка методов (method overloading) не имеет ничего общего с наследованием.
Меня смутил этот момент, но я решил, что Kathy Sierra знать лучше. Скорее всего, он имел ввиду перегрузку наследованного метода.
Имелись в виду переменные состояния.
>Перегрузка методов (method overloading) не имеет ничего общего с наследованием.
Меня смутил этот момент, но я решил, что Kathy Sierra знать лучше. Скорее всего, он имел ввиду перегрузку наследованного метода.
Имелись в виду переменные состояния.
Что такое «переменные состояния» и чем они отличаются от полей?
Меня смутил этот момент, но я решил, что Kathy Sierra знать лучше.
Своей головой думать полезно. Особенно тогда, когда вы пишете пост на хабре от своего имени.
«Код, написанный по принципу инкапсуляции, содержит private переменные, доступ к которым осуществляется через методы (setVarName и getVarName).» — это не инкапсуляция, а полное раскрытие переменной. Инкапсуляция — это нечто большее и другое, но с пониманием этоо бывает куча проблем даже у авторов экзаменов.
Это не полное раскрытие переменной, а необходимое (но не обязательно достаточное) условие инкапсуляции. Заметьте, фраза «доступ осуществляется через два метода» совершенно не означает, что эти методы никак не могут содержать другую логику, помимо доступа. Но даже в тривиальном случае эти методы всегда могут быть перегружены в производном классе или переписаны программистом, так что полного раскрытия доступа не происходит в любом случае.
Извиняюсь, это был ответ на комментарий выше
Нет, это не необходимое условие инкапсуляции. К этим переменным вообще может не быть доступа извне класса.
Просто фраза недостаточно формализована. Я ее читаю примерно так:
Код, написанный по принципу инкапсуляции, МОЖЕТ содержать поля, которые ОБЯЗАНЫ быть приватными, а доступ МОЖЕТ осуществляться ТОЛЬКО через методы (setVarName и getVarName).
Это действительно необходимое условие инкапсуляции.
Впрочем, можно прочитать и как
Код, написанный по принципу инкапсуляции, ОБЯЗАН содержать приватные поля, доступ к которым осуществляется через методы (setVarName и getVarName).
Тогда это будет чушью.
Код, написанный по принципу инкапсуляции, МОЖЕТ содержать поля, которые ОБЯЗАНЫ быть приватными, а доступ МОЖЕТ осуществляться ТОЛЬКО через методы (setVarName и getVarName).
Это действительно необходимое условие инкапсуляции.
Впрочем, можно прочитать и как
Код, написанный по принципу инкапсуляции, ОБЯЗАН содержать приватные поля, доступ к которым осуществляется через методы (setVarName и getVarName).
Тогда это будет чушью.
Мне одному кажется, что переписывание глав книг на хабр это совсем не то, ради чего мы все тут собрались?
Автор, добавьте хотя бы тег перевод к статье.
Автор, добавьте хотя бы тег перевод к статье.
Я бы еще добавил, что вызов конструктора супер-класса должен быть первой строкой в конструкторе.
Вот занятно, кстати. Если дизайн языка таков, что базовый конструктор всегда должен вызываться до наследуемого, то почему не поддержать это синтаксисом? А если мы все-таки позволяем инициализировать в любом порядке, то почему такое правило?
Что вы имеете ввиду под «поддержать это синтаксисом»? Чем плоха ошибка компиляции? Как по мне этого достаточно.
При переопределении методы
…
Должны иметь неизменный тип возвращаемого значения.
java.dzone.com/articles/covariant-return-type-abyssal — враки :)
если честно не совсем понимаю смысла в цикле статей, так как вся изложенная информация есть в JLS, а также книгах с информацией для сдачи SCJP.
…
Должны иметь неизменный тип возвращаемого значения.
java.dzone.com/articles/covariant-return-type-abyssal — враки :)
если честно не совсем понимаю смысла в цикле статей, так как вся изложенная информация есть в JLS, а также книгах с информацией для сдачи SCJP.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Шпаргалка по SCJP. Часть вторая