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

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

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

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

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

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

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

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

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

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

Да, как уже было сказано другими.

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

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

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

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

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

Инкапсуляция - это не безопасность или секреты, а просто организация вещей.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Концепция зеркал была первоначально изобретена в Self , откуда она перенесена в Animorphic Smalltalk / Strongtalk , а затем в новояз . Интересно, что интерфейс отладки Java основан на зеркалах, поэтому разработчики Java (или, скорее, JVM) явно знали о них, но отражение Java нарушено.

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