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

мы используем частные методы только для программной логики, а не для безопасности программ?

Непонятно, что вы подразумеваете под «безопасностью программы». Безопасность не может обсуждаться в вакууме; какие ресурсы вы думаете о защите от каких угроз?

Система безопасности доступа к кодам CLR предназначена для защиты ресурсов пользовательских данных от угрозы враждебного частично доверенного кода, запущенного на машине пользователя .

Поэтому взаимосвязь между отражением, контролем доступа и безопасностью в среде CLR осложняется. Коротко и не совсем точно, эти правила:

• полное доверие означает полное доверие. Полностью доверенный код может получить доступ к каждому отдельному фрагменту памяти в процессе. Это включает частные поля.

• Умение размышлять о частных лицах в частичном доверии контролируется разрешением; если он не будет предоставлен, то код частичного доверия может не отразиться на рядовых.

Подробнее см. http://blogs.msdn.com/b/shawnfa/archive/2006/09/29/777047.aspx .

• Среда CLR на рабочем столе поддерживает режим «ограниченная видимость пропуска», в которой правила взаимодействия рефлексии и системы безопасности несколько отличаются. В принципе, частично доверенный код, который имеет право использовать частное отражение, может обращаться к частному полю через отражение, если частично доверенный код обращается к закрытому полю от типа, который поступает из сборки с равным или меньшим доверием.

Видеть

http://blogs.msdn.com/b/shawnfa/archive/2006/10/05/using-lightweight-codegen-from-partial-trust.aspx

для подробностей

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

Итак: делает ли частное поле защитой от угрозы низкого доверия, пытаясь его прочитать, и тем самым украсть данные пользователя? Да . Защищает ли он его от угрозы высокого доверия, читающего его? Нет . Если код и доверяет пользователю и враждебен пользователю, тогда у пользователя возникает большая проблема . Они не должны были доверять этому коду.

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

Отражение действительно дает возможность обойти модификаторы защиты доступа Java и, следовательно, нарушает строгую инкапсуляцию, как это реализовано в C ++ и Java. Однако это не имеет значения, как вы думаете.

Модификаторы защиты доступа предназначены для того, чтобы помочь программистам разрабатывать модульные системы, основанные на учете, а не быть бескомпромиссными хранителями ворот. Иногда возникают очень серьезные причины для нарушения строгой инкапсуляции, таких как Unit Testing и разработка рамок .

Хотя изначально может быть трудно угаснуть мысль о том, что модификаторы защиты доступа легко обойтись, попробуйте вспомнить, что существует много языков ( Python , Ruby и т. Д.), Которые их вообще не имеют. Эти языки используются для построения больших и сложных систем, таких как языки, которые обеспечивают защиту доступа.

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

Да, но это не проблема.

Инкапсуляция заключается не в безопасности или секретах, а просто в организации вещей.

Отражение не является частью «нормального» программирования. Если вы хотите использовать его для разрыва инкапсуляции, вы принимаете риски (проблемы с версиями и т. Д.),

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

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

Я начал с «это не проблема». Я имел в виду: до тех пор, пока вы используете отражение, как предполагалось. И осторожно.

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

Данные – это данные, если кто-то определен достаточно, они могут делать что-либо с вашим кодом. Буквально ничего.

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

Нет, отражение не нарушает идею частных методов. По крайней мере, по сути. Ничто не говорит о том, что отражение не может подчиняться ограничениям доступа.

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

Что я имею в виду, плохо спроектированный ? Ну, как я сказал выше, нет ничего, что мешает вам иметь язык, на котором отражение подчиняется ограничениям доступа. Проблема заключается в том, что, например, отладчики, профилировщики, средства покрытия, IntelliSense, IDE, инструменты вообще должны иметь возможность нарушать ограничения доступа. Поскольку нет способа представить разные варианты отражения для разных клиентов, большинство языков предпочитают инструменты для обеспечения безопасности. (E – контрпример, который абсолютно не имеет отражающих возможностей, как сознательный выбор дизайна.)

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

Итак, в чем заключается идея плохого дизайна ? Хорошо, обратите внимание на слово «ответственный» в вышеуказанном абзаце. Каждый объект отвечает за размышление о себе. Кроме того, каждый объект несет ответственность за все, за что он был написан в первую очередь. Другими словами: каждый объект имеет как минимум две обязанности. Это нарушает один из основных принципов объектно-ориентированного проектирования: принцип единой ответственности.

Решение довольно просто: разбивайте объект. Первоначальный объект просто отвечает за все, за что он был изначально написан. И есть еще один объект (называемый Зеркалом, потому что это объект, который отражает другие объекты), который отвечает за отражение. И теперь, когда ответственность за отражение разбивается на отдельный объект, что мешает нам иметь не одно, а два, три, много зеркальных объектов? Тот, который соблюдает ограничения доступа, который позволяет объекту отражать сам себя, но не любые другие объекты, которые позволяют только интроспекцию (то есть только для чтения), такую, которая позволяет отражать только информацию, доступную только для чтения (т. Е. Для профилировщик), который обеспечивает полный доступ ко всей системе, включая нарушение ограничений доступа (для отладчика), который предоставляет доступ только для чтения к именам методов и подписям и соблюдает ограничения доступа (для IntelliSense) и так далее …

В качестве приятного бонуса это означает, что Зеркала – это по существу возможности (в смысле безопасности безопасности) для отражения. IOW: Зеркала – это Святой Грааль в десятилетнем стремлении согласовать динамическое метапрограммирование безопасности и времени выполнения.

Понятие Зеркала первоначально было изобретено в « Я», откуда оно переносилось в Animorphic Smalltalk / Strongtalk, а затем в Newspeak . Интересно, что интерфейс Java Debugging основан на зеркалах, поэтому разработчики Java (или, скорее, JVM) четко знали о них, но отражение Java нарушено.

Это, как и другие, уже сказано.

Тем не менее, я помню, что в Java может быть активный менеджер безопасности, который может помешать вам получить доступ к каким-либо частным методам, даже с отражением, если у вас нет прав на это. Если вы запускаете свою локальную JVM, такой менеджер обычно неактивен.

Да, размышление нарушает эту идею. У родных языков также есть некоторые трюки, чтобы нарушить правила ООП, например, в C ++ можно изменять членов частного класса с помощью трюков-указателей. Однако, используя эти трюки, мы получаем код, который может быть несовместим с будущими версиями класса – это цена, которую мы платим за нарушение правил ООП.

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

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

Обратите внимание, что инкапсуляция! = Безопасность. Инкапсуляция – это объектно-ориентированная концепция дизайна и предназначена только для улучшения дизайна. Для безопасности в Java есть SecurityManager .

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

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

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

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

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

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

Да, он разрушает инкапсуляцию. Но есть много веских причин использовать его в некоторых ситуациях.

Например:

Я использую MSCaptcha на некоторых веб-сайтах, но он отображает <div> вокруг тега <img>, который смешивается с моим HTML. Затем я могу использовать стандартный тег <img> и использовать отражение, чтобы получить значение идентификатора изображения captcha для создания URL-адреса.

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

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

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

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

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