Разрушает ли рефлексия идею частных методов, потому что частные методы могут быть доступны вне класса?

Question

Разрушает ли рефлексия идею частных методов? Потому что частные методы могут быть доступны извне класса? (Может быть, я не понимаю смысл отражения или пропустить что-то еще, пожалуйста, скажите мне) http://en.wikipedia.org/wiki/Reflection_%28computer_science%29

Edit: Если перебор нарушает идею частных методов - используем ли мы частные методы только для логики программы, а не для безопасности программы?

Спасибо

Answer 1

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

Например,класс может хранить в некоторой переменной зашифрованную версию дескриптора ОС для своего главного окна.Используя отражение, другой класс мог видеть эту переменную, но, не зная метода шифрования, он не мог определить окно, к которому он принадлежал, или заставить переменную ссылаться на другое окно.

Я видел классы, которые утверждают, что действуюткак «универсальные сериализаторы»;они могут быть очень полезны, если применяются к чему-то вроде класса контейнера для хранения данных, в котором отсутствует атрибут «сериализуемый», но в остальном все просто.Они будут издавать гоблиды, если их применять к любому классу, создатель которого стремился затенить вещи.

Answer 2

Да.Отражение нарушает принцип инкапсуляции.Это не только для доступа к закрытым членам, но и для раскрытия всей структуры класса.

Answer 3

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

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

Answer 4

контроль доступа через private / protected / package / public не предназначен в первую очередь для безопасности.

это помогает хорошим парням делать правильные вещи, но не мешает плохим парням делать неправильные вещи.

как правило, мы предполагаем, что другие - хорошие парни, и мы включаем их код в наше приложение, хотя.

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