Я предполагаю, что вы говорите о публичных, частных и защищенных методах здесь?
Если так, то они не существуют в целях безопасности. Они существуют для того, чтобы упростить или гарантировать правильную модульность программного обеспечения. (Удастся ли им в этом - это спор, который я оставлю для других. Однако это видение того, для чего они нужны.)
Предположим, что я доставляю библиотеку, затем я могу свободно доставить другую версию библиотеки и изменить содержимое, помеченное как личное, сколько захочу. Напротив, если бы я не пометил этот материал как частный, то я не смог бы изменить какие-либо внутренние компоненты моего программного обеспечения, потому что кто-то где-то, вероятно, имеет к нему доступ напрямую. Конечно, в теории это их вина за то, что они не использовали документированный API. Но клиент воспримет это как мою ошибку, что мое обновление программного обеспечения сломало их программное обеспечение. Они не хотят оправданий, они хотят, чтобы это исправили. Но если я не позволю им иметь доступ с самого начала, то мой API - это именно публичные методы, которые я намеревался использовать в качестве API, и проблема устранена.
Вторая наиболее вероятная вещь, о которой вы могли бы говорить, это модель безопасности Java. Если вы говорите об этом, то причина, по которой он существует, заключалась в том, что первоначальное видение Java включало людей, отправляющих, возможно, ненадежные апплеты для интерактивной работы внутри сторонних программ (например, браузеров). Поэтому модель безопасности должна была предоставить пользователям некоторую защиту от вредоносных апплетов. Поэтому угроза безопасности, о которой следует беспокоиться и защищать, - это ненадежные апплеты, пытающиеся взаимодействовать с другим программным обеспечением, которое может быть загружено.