Существуют ли другие модификаторы точки доступа, кроме лучшей читабельности?

Question

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

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

Answer 1

Да, их можно обойти. Пример внедрения зависимости, который вы указали, на самом деле является полезным примером обхода. Инъекция частным пользователям не загрязняет интерфейсы и не так легко запутаться во время выполнения. Однако, чтобы увидеть основное преимущество, подумайте о том, что вы разработчик программного обеспечения и возглавляете очень ленивую или неопытную команду.

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

Модификаторы доступа показывают некоторые намерения за интерфейсом, определенным для объекта. Обычно, если вы пишете хорошо продуманный код, вам почти всегда нужны только публичные и приватные модификаторы. В редком случае, когда проблема не может быть легко / четко разделена на один сплоченный объект, существует также ключевое слово «защищенный», которое позволяет ограничить внешний доступ к объектам, которые должны логически разделять данную проблему.

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

ТЛ; др:

Замечательное применение компилятором модификаторов доступа. Компилятор создает довольно хороший барьер неудобств для тех, кто в противном случае был бы рад уменьшить сплоченность и увеличить сцепление вашей кодовой базы, чтобы быстрее вычеркнуть их непосредственную задачу.

Answer 2

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

Как автор класса, вы должны исходить из того, что ваши модификаторы доступа не будут обойдены.Это позволяет вам делать более точные предположения о состоянии вашего объекта перед вызовом методов.Вы знаете точно, откуда будут вызываться методы private и в каком состоянии находится объект. Вы не можете делать те же предположения относительно public методов.

Пример можетможет быть, метод private может получить доступ к некоторому общему состоянию в многопоточном контексте, зная, что он был вызван из другого метода, который удерживает блокировку общего состояния, тогда как методам public может потребоваться получить блокировкудо доступа к общему ресурсу.

Answer 3

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

Плюс они сигнализируют о внутреннем и внешнем / намерении API. Если вы игнорируете это как пользователь, вы признаете, что открыли себя для будущих проблем.

Answer 4

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

Answer 5

этот модификатор может быть обойден (частный пакет и защищенный - внедрение пакета; любой - отражение).

Если вы работаете с менеджером безопасности и подписанными JAR, ни то, ни другое невозможно. Таким образом, модификаторы доступа могут фактически использоваться в качестве механизма безопасности в контролируемых средах.

Однако в подавляющем большинстве случаев их целью действительно является организация кода (я не думаю, что читаемость - правильное слово).

Answer 6

Частная / защищенная помощь делает код более безопасным и предотвращает тесную связь, что, в свою очередь, облегчает повторное использование, снижает затраты на обслуживание. Я мог бы идти весь день!