Отражает ли отражение идею частных методов? Потому что частные методы могут быть доступны извне класса? (Может быть, я не понимаю смысла размышлений или пропущу что-то еще, скажите, пожалуйста) http://en.wikipedia.org/wiki/Reflection_%28computer_science%29
Edit: Если отклонение нарушает идею частных методов - используем ли мы частные методы только для логики программы, а не для безопасности программ?
Спасибо
Используем ли частные методы только для программной логики, а не для безопасности программ?
Неясно, что вы подразумеваете под "безопасностью программы". Безопасность не может обсуждаться в вакууме; какие ресурсы вы думаете о защите от каких угроз?
Система безопасности доступа к кодам CLR предназначена для защиты ресурсов пользовательских данных от угрозы враждебного частично доверенного кода, запущенного на машине пользователя.
Таким образом, взаимосвязь между отражением, контролем доступа и безопасностью в среде CLR является сложной. Вкратце и не совсем точно, правила следующие:
полное доверие означает полное доверие. Полностью доверенный код может получить доступ к каждому отдельному фрагменту памяти в этом процессе. Включает частные поля.
Возможность размышлять над частными лицами в частичном доверии контролируется разрешением; если он не предоставлен, то частичный код доверия не может отражать рядовых.
Подробнее см. http://blogs.msdn.com/b/shawnfa/archive/2006/09/29/777047.aspx.
См
http://blogs.msdn.com/b/shawnfa/archive/2006/10/05/using-lightweight-codegen-from-partial-trust.aspx
для деталей
Резюме состоит в следующем: вы можете заблокировать частично доверенный код достаточно, чтобы он не мог использовать отражение, чтобы посмотреть на личные вещи. Вы не можете заблокировать полный код доверия; почему он назвал "полное доверие". Если вы хотите ограничить его, не доверяйте ему.
Итак: делает ли частное поле защитой от угрозы низкого кода доверия, пытающегося его прочитать, и тем самым крадет пользовательские данные? Да. Защищает ли он его от угрозы высокого кода доверия, читающего его? Нет. Если код и доверяет пользователю и враждебен пользователю, тогда у пользователя возникает большая проблема. Они не должны были доверять этому коду.
Обратите внимание, что, например, закрытие поля не защищает секрет вашего кода от пользователя, у которого есть ваш код, и он враждебен вам. Система безопасности защищает хороших пользователей от злого кода. Он не защищает хороший код от злых пользователей. Если вы хотите сделать что-то частное, чтобы сохранить его от пользователя, вы выполняете безумное поручение. Если вы хотите сделать это частным, чтобы хранить секрет от злобных хакеров, которые заманили пользователя в запущенный враждебный код с низким доверием, это хорошая техника.
Отражение действительно обеспечивает способ обойти модификаторы защиты Java Access, поэтому нарушает строгую инкапсуляцию, как это реализовано в С++ и Java. Однако это не имеет значения, как вы думаете.
Модификаторы защиты доступа предназначены для того, чтобы помочь программистам разрабатывать модульные системы, основанные на учете, а не быть бескомпромиссными хранителями ворот. Иногда возникают очень серьезные причины для нарушения строгой инкапсуляции, таких как Unit Testing и разработка рамок.
В то время как изначально может быть трудно угаснуть мысль о том, что модификаторы защиты доступа легко обойтись, попробуйте вспомнить, что существует много языков (Python, Ruby и т.д.), которые их вообще не имеют. Эти языки используются для создания больших и сложных систем, таких как языки, которые обеспечивают защиту доступа.
Есть некоторые дебаты о том, являются ли модификаторы защиты доступа помощь или препятствие. Даже если вы действительно цените доступ к защите, относитесь к ней как к руке помощи, а не к созданию или разрушению вашего проекта.
Да, но это не проблема.
Инкапсуляция не касается безопасности или секретов, а просто для организации вещей.
Отражение не является частью "нормального" программирования. Если вы хотите использовать его для разрыва инкапсуляции, вы принимаете риски (проблемы с версиями и т.д.).
Отражение следует использовать только тогда, когда нет лучших (менее инвазивных) способов выполнения чего-либо.
Отражение предназначено для "инструментария" системного уровня, например, для сопоставления персистентности, и должно быть убрано в хорошо протестированных библиотеках. Я бы нашел какое-либо использование отражения при подозрении на нормальный код приложения.
Я начал с "это не проблема". Я имел в виду: до тех пор, пока вы используете отражение, как предполагалось. И осторожно.
Это как твой дом. Замки оставляют только честных людей или людей, которые не хотят выбирать ваш замок.
Данные - это данные, если кто-то определен достаточно, они могут делать что-либо с вашим кодом. Буквально что угодно.
Итак, да, размышление позволит людям делать то, что вы не хотите, чтобы они делали с вашим кодом, например, получить доступ к закрытым полям и методам. Однако важно то, что люди не случайно это сделают. Если они используют рефлексию, они знают, что делают то, что они, вероятно, не собираются делать, точно так же, как никто случайно не блокирует замок на вашей передней двери.
Нет, отражение не нарушает идею частных методов. По крайней мере, по сути. Ничто не говорит о том, что отражение не может подчиняться ограничениям доступа.
Плохо спроектированное отражение нарушает идею частных методов, но это не имеет ничего общего с отражением как таковым: все, что плохо спроектировано, может нарушить идею частных методов. В частности, плохой дизайн частных методов также может явно нарушить идею частных методов.
Что я имею в виду, плохо спроектированный? Ну, как я сказал выше, нет ничего, что мешает вам иметь язык, на котором отражение подчиняется ограничениям доступа. Проблема заключается в том, что, например, отладчики, профилировщики, инструменты покрытия, IntelliSense, IDE, инструменты вообще должны иметь возможность нарушать ограничения доступа. Поскольку нет способа представить разные варианты отражения для разных клиентов, большинство языков предпочитают инструменты для обеспечения безопасности. (E - контрпример, который абсолютно не имеет отражающих возможностей, как сознательный выбор дизайна.)
Но кто говорит, что вы не можете представить разные варианты отражения для разных клиентов? Ну, проблема в том, что в классической реализации рефлексии все объекты отвечают за то, что они отражаются на себе, и поскольку есть только один из каждого объекта, может быть только версия отражения.
Итак, в чем заключается идея плохого дизайна? Хорошо, обратите внимание на слово "ответственный" в вышеуказанном абзаце. Каждый объект отвечает за размышление о себе. Кроме того, каждый объект несет ответственность за все, за что он был написан в первую очередь. Другими словами: каждый объект имеет как минимум две обязанности. Это нарушает один из основных принципов объектно-ориентированного проектирования: принцип единой ответственности.
Решение довольно просто: разбить объект. Первоначальный объект просто отвечает за все, за что он был изначально написан. И есть еще один объект (называемый Зеркалом, потому что это объект, который отражает другие объекты), который отвечает за отражение. И теперь, когда ответственность за отражение разбивается на отдельный объект, что мешает нам иметь не одно, а два, три, много зеркальных объектов? Тот, который соблюдает ограничения доступа, который позволяет объекту отражать сам себя, но не любые другие объекты, которые позволяют только интроспекцию (то есть только для чтения), такую, которая позволяет отражать только информацию, доступную только для чтения (т.е. Для профилировщик), который обеспечивает полный доступ ко всей системе, включая нарушение ограничений доступа (для отладчика), которое предоставляет доступ только для чтения к именам методов и подписям и соблюдает ограничения доступа (для IntelliSense) и т.д. & hellip;
В качестве приятного бонуса это означает, что Зеркала - это по существу возможности (в смысле безопасности безопасности) для отражения. IOW: Зеркала - это Святой Грааль в десятилетнем поиске, чтобы согласовать динамическое метапрограммирование безопасности и времени выполнения.
Концепция Зеркала была первоначально изобретена в Self, откуда она перенесена в Animorphic Smalltalk/Strongtalk, а затем Newspeak. Интересно, что интерфейс Java Debugging основан на зеркалах, поэтому разработчики Java (или, скорее, JVM) четко знали о них, но отражение Java нарушено.
Он, как и другие, уже заявил.
Тем не менее, я помню, что в Java может быть активен менеджер безопасности, который может помешать вам получить доступ к каким-либо приватным методам, даже с отражением, если у вас нет прав на это. Если вы запускаете свою локальную JVM, такой менеджер обычно неактивен.
Да, размышление нарушает эту идею. У родных языков также есть некоторые трюки, чтобы нарушить правила ООП, например, в С++ можно изменять членов частного класса с помощью трюков-указателей. Однако, используя эти трюки, мы получаем код, который может быть несовместим с будущими версиями класса - это цена, которую мы платим за нарушение правил ООП.
Да, отражение может быть использовано для нарушения инкапсуляции и даже для неправильного поведения. Имейте в виду, что сборке нужно доверять, чтобы выполнять отражение, поэтому все еще существуют некоторые меры защиты.
Да, он разбивает инкапсуляцию, если вы этого хотите. Тем не менее, его можно использовать для хорошего использования - например, для написания модульных тестов для частных методов, а иногда - как я узнал из своего собственного опыта - обход ошибок в сторонних API:)
Обратите внимание, что инкапсуляция!= безопасность. Инкапсуляция - это объектно-ориентированная концепция дизайна и предназначена только для улучшения дизайна. Для обеспечения безопасности в java есть SecurityManager.
Я думаю, что это вопрос мнения, но если вы используете рефлексию, чтобы обойти инкапсуляцию, внедренную разработчиком в класс, то вы побеждаете цель.
Итак, чтобы ответить на ваш вопрос, он нарушает идею инкапсуляции (или скрытия информации), которая просто утверждает, что частные свойства/методы являются частными, поэтому они не могут быть удалены из класса вне класса.
Да. Отражение нарушает принцип инкапсуляции. Это не только для доступа к частным членам, но и для раскрытия всей структуры класса.
Отражение позволяет любому классу CLR исследовать и управлять свойствами и полями других классов CLR, но не обязательно делать это разумно. Это позволяет классу заслонять смысл свойств и полей или защищать их от несанкционированного доступа, поскольку они зависят неявным образом друг от друга, статические поля, информация о ОС и т.д.
Например, класс может хранить в некоторой переменной зашифрованную версию дескриптора ОС для своего главного окна. Используя отражение, другой класс мог видеть эту переменную, но не зная метода шифрования, он не мог идентифицировать окно, к которому он принадлежал, или сделать переменную ссылкой на другое окно.
Я видел классы, претендующие на роль универсальных сериализаторов; они могут быть очень полезны, если применить их к чему-то вроде класса хранилища данных-контейнера, в котором отсутствует атрибут "serializable", но в остальном он абсолютно прост. Они будут производить gobbledygook, если они будут применены к любому классу, чей создатель попытался скрыть вещи.
Да, он разрушает инкапсуляцию. Но есть много веских причин использовать его в некоторых ситуациях.
Например:
Я использую MSCaptcha на некоторых веб-сайтах, но он отображает <div> вокруг <img> , который помешает моему HTML. Тогда я могу использовать стандартный <img> и использовать отражение, чтобы получить значение идентификатора изображения captcha для создания URL-адреса.
Идентификатор изображения является частным свойством, но с использованием отражения я могу получить это значение.
контроль доступа через private/protected/package/public в первую очередь не предназначен для обеспечения безопасности.
он помогает хорошим парням поступать правильно, но не мешает плохим парням делать неправильные вещи.
В общем, мы предполагаем, что другие хорошие парни, и мы включили их код в наше приложение, хотя, несмотря на это.
Если вы не можете доверять парню из библиотеки, которую вы включаете, вы ввернуты.