Р
Size: a a a
2020 April 30
СХ
Спасибо за ответ, но не совсем то, что я хотел. Protected открывает доступ для потомков и в пределах пакета, т.е. я могу получить доступ к полю и даже переопределить его не используя геттеры и сеттеры. А хотелось бы иметь способ открыть поле, чтобы его мог использовать потомок внутри себя, но его нельзя было использовать извне без интерфейсов
РН
Сергей Хос
Спасибо за ответ, но не совсем то, что я хотел. Protected открывает доступ для потомков и в пределах пакета, т.е. я могу получить доступ к полю и даже переопределить его не используя геттеры и сеттеры. А хотелось бы иметь способ открыть поле, чтобы его мог использовать потомок внутри себя, но его нельзя было использовать извне без интерфейсов
БС
Сергей Хос
Спасибо за ответ, но не совсем то, что я хотел. Protected открывает доступ для потомков и в пределах пакета, т.е. я могу получить доступ к полю и даже переопределить его не используя геттеры и сеттеры. А хотелось бы иметь способ открыть поле, чтобы его мог использовать потомок внутри себя, но его нельзя было использовать извне без интерфейсов
Если я правильно понимаю, твоя идея нарушает open closed principle. Давая доступ к приватному полю наследнику ты позволяешь ему изменять состояние родителя. А он должен только расширять.
СХ
Смысл такой. Есть родитель с приватными полями, у потомка инициализируем эти поля в конструкторе и потом хотим использовать эти поля в потомке
D
Сергей Хос
Смысл такой. Есть родитель с приватными полями, у потомка инициализируем эти поля в конструкторе и потом хотим использовать эти поля в потомке
сеттеры/геттеры в помощь. Но прямой доступ к полям - очень-очень плохая практика. Переопределяй конструкторы, если нужно, но не должно быть прямого доступа к полям у потомков класса
РН
можешь попробовать использовать композицию вместо наследования
N
Конструктор потомка инициализирует поля потомка. Если нужны значения полей суперкласса, то бери их геттером и присваивай эти значения полям потомка.
БС
Сергей Хос
Смысл такой. Есть родитель с приватными полями, у потомка инициализируем эти поля в конструкторе и потом хотим использовать эти поля в потомке
Чот вообще идея хромая. Делать в родителе две характеристики, которые в случае прямоугольника значат одно а в случае круга - другое? А потом появится наследник, в котором нужна третья характеристика. Не, это прям плохой путь.
СХ
Чот вообще идея хромая. Делать в родителе две характеристики, которые в случае прямоугольника значат одно а в случае круга - другое? А потом появится наследник, в котором нужна третья характеристика. Не, это прям плохой путь.
Это не прикладная задача, просто изучаю возможности языка
БС
не понимаю какие поля в абстрактном по сути родителе - зачем? Они в родителе смысла не имеют.
СХ
читаю Шилда, он использовал это просто для примера
ПЛ
Привет всем! народ ну киньте в меня камнем (да помногоядернее) - не получается у меня создать jar из идеи, c встроенными библиотеками вот есть pom и jar-with-dependencies и структура проекта : https://pastebin.com/LWNzrxpr
https://pastebin.com/mrqi4rrj
https://pastebin.com/mrqi4rrj
YG
Сергей Хос
читаю Шилда, он использовал это просто для примера
Просто есть очень много возможностей которые лучше вообще не использовать
YG
Само наследование то многие ставят под сомнение, а тут такое