Java-риск между защищенным и общедоступным

Когда я пытаюсь получить доступ и переопределить унаследованную абстрактную функцию из абстрактного класса с защищенным уровнем доступа,

protected <ReturnDataType> <FunctionName>() {

после удаления защищенного типа доступа Eclipse выдает мне эту ошибку

Невозможно уменьшить видимость унаследованного метода от ‹ унаследованного класса >

который разрешается с помощью быстрого исправления, присваивающего ему тип доступа Protected.

Я знаю, что у меня также может быть тип доступа Public для этой переопределенной функции.

Теперь мой вопрос: каков риск/проблема, связанная с тем, что я использую эту функцию как общедоступную?


java inheritance public protected
person ItsMeGokul    schedule 22.01.2018    source источник
comment
Я не уверен, что в этом есть риск. Я думаю, это просто, хотите ли вы, чтобы любой другой метод в системе мог получить доступ к вашему методу, или если вы хотите разрешить доступ только классам, которые наследуются от вашего класса. Это полностью зависит от вас.   -  person markspace    schedule 22.01.2018
comment
Обобщенно оценить риск сложно. Это зависит от архитектуры ваших приложений и от того, что вам нужно/хотите показать. В общем, вы хотите свести количество публичных участников к минимуму. Любой общедоступный метод может быть легко использован непреднамеренно, что может привести к раскрытию данных, которые не должны быть раскрыты, и увеличить возможный вектор атаки на вашу систему. Кроме того, я не уверен, как оценить риск вашего конкретного приложения.   -  person tatmanblue    schedule 22.01.2018
comment
Лучшее объяснение проблемы можно найти в известной книге «Эффективный Java». Пункт 15. Минимизируйте доступность классов и членов.   -  person Boris    schedule 22.01.2018

Ответы (2)


arrow_upward
0
arrow_downward

Это средство защиты вашего кода от ошибок. Существуют языки программирования без инкапсуляции. В самом крайнем случае, любой код может изменить любую часть любых данных, и мы можем просто не хотеть, чтобы это было возможно. Дисциплинированный кодер уменьшит количество мест, где манипулируют данными данного типа, но все же могут быть не очевидны все комбинации операций, которые могут оставлять объекты* в разных состояниях. Ситуация ухудшается, когда их код затем используется как часть чужого кода. Таким образом, риск изменения этих типов доступа заключается в том, что это может привести к ошибкам в дальнейшем при неправильном использовании.

person Cowboy Farnz    schedule 22.01.2018
comment
Я думаю, вы лучше поймете, почему это не разрешено в повторяющемся вопросе. Ваш ответ близок, но не совсем там. - person Makoto; 22.01.2018

arrow_upward
-1
arrow_downward

Все, что делает public, — это разрешает доступ к переменной через другой пакет, поэтому, если кто-то импортирует ваш проект в качестве внешней библиотеки в свой проект, он сможет получить доступ к глобальной переменной. Эта страница может быть вам полезна: https://docs.oracle.com/javase/tutorial/java/javaOO/accesscontrol.html

person Alex Finch    schedule 22.01.2018