Частные члены действительно более "безопасны" на Java?

Изучение Java Мне иногда учили использовать модификатор доступа private, чтобы не подвергать "конфиденциальную информацию" другим классам, как если бы это могло открыть законное отверстие безопасности. Но я никогда не сталкивался с ситуацией, когда ограничение видимости элементов было более чем удобством для моделирования программы объектно-ориентированным способом.

Являются ли private поля и функции в Java-классах более "безопасными", чем в противном случае?

EDIT - сборник лучших ответов.

Почему private не означает "безопасный":

  • декомпиляторы позволяют статический просмотр байт-кода
  • отражает библиотеку времени выполнения для частных членов.

Что private полезно для:

  • поддерживаемость кода из-за принудительного доступа на уровне метода
  • модульность кода, скрывая детали реализации

Ответы

Ответ 1

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

Наличие членов private - проблема ремонтопригодности. Если я дам только доступ на уровне метода к моим внутренним элементам, то моя единственная ответственность - обеспечить, чтобы мои методы API продолжали работать. Я не блокирован использованием Double по сравнению с BigDecimal на внутренней стороне, если мои методы продолжают возвращать Double (например).

Ответ 2

Нет, они не более "безопасны" в этом смысле, хотя некоторые (очень плохие) книги на Java пытаются объяснить private таким образом. Если у злоумышленника была возможность вызвать произвольный Java-код в вашем процессе, все "безопасность" уже исчезла. И как еще один ответ уже упоминался, отражение может обойти модификатор доступа private.

Ответ 3

private на самом деле не для безопасности, поскольку отражение может обойти его (по модулю classloader/secure classloader stuff). Он служит индикатором намерения и является препятствием для одного типа ошибок программирования.

Но рассмотрите сторонних пользователей API API, которые даже не видят свойства или методы private. Это не просто о вашем собственном коде, а о том, какой код подвергается другим. (Опять глядя на это с точки зрения "Я не пытаюсь войти в код" ).

Ответ 4

Что касается безопасности, ответ "на самом деле": определенные хакеры могут попасть в ваши частные поля и вызвать ваши частные функции с небольшим отражением; все, что им нужно, это JAR с вашим кодом.

Хотя скрытие "чувствительной" информации не делает ваш класс более безопасным, он делает его (наряду с системами, построенными из него) намного более удобным. Таким образом, этот ответ не является поводом для того, чтобы публиковать всех членов ваших классов.

Ответ 5

Я согласен в целом с ответами до сих пор (т.е. что private действительно для гигиены кода не является реальной безопасностью). В разных ответах указывалось, что вы можете обойти private с помощью отражения. Обратите внимание, что вы можете, в свою очередь, отключить отражение, если вы включите Java SecurityManager. См., В частности, ReflectPermission. Однако менеджеры по безопасности редко используются (за пределами обычной песочницы для браузера).

Ответ 6

Очевидно, что принципы создания всех частных, где это возможно, применяются только в том случае, если вы придерживаетесь принципа open-closed, иначе, если люди привыкнут к идее для редактирования внутренних объектов существующих классов вместо их расширения они могут изменить инкапсуляцию частных переменных-членов через их доступность через мутаторы и аксессоры или изменение модификатора доступа.

Ответ 7

Я думаю, что смысл "безопасности" вашего инструктора состоял не в том, чтобы держать хакеров, а скорее за счет ошибок. Делая все как можно более приватным, вы ограничиваете способы, которыми один класс может общаться с другим классом, не зная его. Это пример Модульное программирование.

Ответ 8

Btw: отражение в Java фактически позволяет вам переопределять модификаторы доступа к полям объектов. См. javadoc и example.