反射是否打破了私有方法的想法，因为私有方法可以在类外部访问？
反射是否打破了私有方法的思想？因为私有方法可以从类外部访问？ （可能是我没理解反射的意思或者漏掉了什么，请告诉我） http://en.wikipedia.org/wiki/Reflection_%28computer_science%29
编辑： 如果反射打破了私有方法的想法——我们是否仅将私有方法用于程序逻辑而不是程序安全？
谢谢
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（14）
目前尚不清楚“程序安全”是什么意思。安全问题不能在真空中讨论；您正在考虑保护哪些资源免受哪些威胁？
CLR 代码访问安全系统旨在保护用户数据资源免受在用户计算机上运行的恶意部分可信代码的威胁。
因此，CLR 中的反射、访问控制和安全性之间的关系很复杂。简而言之，但不完全准确，规则如下：
完全信任意味着完全信任。 完全可信的代码可以访问进程中的每一位内存。其中包括私有字段。
在部分信任中反思私人的能力是由许可控制的；如果未授予，则部分信任代码可能不会对私有进行反射。
有关详细信息，请参阅链接。
如果部分受信任的代码从来自具有 equal 或 less 的程序集的类型访问私有字段，则有权使用私有反射的部分受信任的代码可以通过反射访问私有字段信任。
请参阅
链接
执行
摘要是：您可以充分锁定部分受信任的代码，使其无法使用反射来查看私有内容。您无法锁定完全信任代码；这就是为什么它被称为“完全信任”。如果您想限制它，那么就不要信任它。
那么：将字段设置为私有是否可以保护它免受低信任代码试图读取它的威胁，从而窃取用户数据？ 是。它是否可以保护它免受高信任代码读取的威胁？ 不。如果代码既受到用户信任，又对用户怀有敌意，那么用户就会遇到大问题。他们不应该信任该代码。
请注意，例如，将字段设置为私有并不能保护代码中的秘密免受拥有您代码且对您怀有敌意的用户的侵害。安全系统保护好用户免受邪恶代码的侵害。它不能保护好的代码免受邪恶用户的侵害。如果您想将某些内容设为私有以防止用户看到它，那么您的任务就是白费力气。如果您想将其设为私有，以防止邪恶的黑客引诱用户运行恶意的低信任代码，那么这是一个很好的技术。
It is not clear what you mean by "program security". Security cannot be discussed in a vacuum; what resources are you thinking of protecting against what threats?
The CLR code access security system is intended to protect resources of user data from the threat of hostile partially trusted code running on the user's machine.
The relationship between reflection, access control and security in the CLR is therefore complicated. Briefly and not entirely accurately, the rules are these:
full trust means full trust. Fully trusted code can access every single bit of memory in the process. That includes private fields.
The ability to reflect on privates in partial trust is controlled by a permission; if it is not granted then partial trust code may not do reflection on privates.
See Link for details.
partially trusted code that has the right to use private reflection may access a private field via reflection if the partially trusted code is accessing a private field from a type that comes from an assembly with equal or less trust.
See
Link
for details
The executive summary is: you can lock partially trusted code down sufficiently that it is not able to use reflection to look at private stuff. You cannot lock down full trust code; that's why it's called "full trust". If you want to restrict it then don't trust it.
So: does making a field private protect it from the threat of low trust code attempting to read it, and thereby steal user's data? Yes. Does it protect it from the threat of high trust code reading it? No. If the code is both trusted by the user and hostile to the user then the user has a big problem. They should not have trusted that code.
Note that for example, making a field private does not protect a secret in your code from a user who has your code and is hostile to you. The security system protects good users from evil code. It doesn't protect good code from evil users. If you want to make something private to keep it from a user then you are on a fool's errand. If you want to make it private to keep a secret from evil hackers who have lured the user into running hostile low-trust code then that is a good technique.
反射确实提供了一种规避 Java 访问保护修饰符的方法，因此它在 C++ 和 Java 中实现时违反了严格封装。然而，这并不像您想象的那么重要。
访问保护修改器旨在帮助程序员开发模块化的精心设计的系统，而不是成为不妥协的看门人。有时有很好的理由打破严格的封装，例如单元测试和框架开发< /强>。
虽然一开始可能很难接受访问保护修饰符很容易被规避的想法，但请记住，有很多种语言（Python 、Ruby 等）根本没有它们。这些语言用于构建大型且复杂的系统，就像提供访问保护的语言一样。
关于访问保护修饰符是帮助还是阻碍存在一些争论。即使您确实重视访问保护，也请将其视为援助之手，而不是项目的成败。
Reflection does provide a way to circumvent Java's Access Protection Modifiers and therefore violates strict encapsulation as it realised in C++ and Java. However this does not matter as much as you might think.
Access Protection Modifiers are intended to assist programmers to develop modular well factored systems, not to be uncompromising gate keepers. There are sometimes very good reasons to break strict encapsulation such as Unit Testing and framework development.
While it may initially be difficult to stomach the idea that Access Protection Modifiers are easily circumventable, try to remember that there are many languages (Python, Ruby etc.) that do not have them at all. These languages are used to build large and complex systems just like languages which do provide access protection.
There is some debate on whether Access Protection Modifiers are a help or a hindrance. Even if you do value access protection treat it like a helping hand, not the making or breaking of your project.
是的，但这不是问题。
封装与安全或秘密无关，而只是与组织事物有关。
反射不是“正常”编程的一部分。如果你想用它来打破封装，你就接受了风险（版本控制问题等）。
只有当没有更好（侵入性较小）的方法来完成某些事情时才应该使用反射。
反射适用于持久性映射等系统级“工具”，应该隐藏在经过良好测试的库中。我会发现在正常应用程序代码中任何使用反射的行为都是可疑的。
我从“这不是问题”开始。我的意思是：只要你按预期使用反射即可。并且小心。
Yes, but it is not a problem.
Encapsulation is not about security or secrets, just about organizing things.
Reflection is not part of 'normal' programming. If you want to use it to break encapsulation, you accept the risks (versioning problems etc)
Reflection should only be used when there are no better (less invasive) ways to accomplish something.
Reflection is for system-level 'tooling' like persistence mapping and should be tucked away in well tested libraries. I would find any use of reflection in normal application code suspect.
I started with "it is not a problem". I meant: as long as you use reflection as intended. And careful.
这就像你的房子。锁只会挡住诚实的人，或者那些不愿意撬你的锁的人。
数据就是数据，如果有人有足够的决心，他们可以用你的代码做任何事情。字面上的任何东西。
所以，是的，反射将允许人们做你不希望他们用你的代码做的事情，例如访问私有字段和方法。然而，重要的是人们不会无意中这样做。如果他们使用反射，他们就知道自己正在做一些他们可能不打算做的事情，就像没有人不小心撬开了你前门的锁一样。
It's like your house. Locks only keep out honest people, or people who aren't willing to pick your lock.
Data is data, if someone is determined enough, they can do anything with your code. Literally anything.
So yes, reflection will allow people to do things you don't want them to do with your code, for example access private fields and methods. However, the important thing is that people will not accidentally do this. If they're using reflection, they know they're doing something they probably aren't intended to do, just like no one accidentally picks the lock on your front door.
不，反射不会破坏私有方法的思想。至少本身不是。没有任何内容表明反射不能遵守访问限制。
设计不良反射破坏了私有方法的思想，但这与反射本身没有任何关系：任何设计不良都可能破坏私有方法的思想。特别是，私有方法的糟糕设计也会明显破坏私有方法的思想。
设计糟糕是什么意思？好吧，正如我上面所说，没有什么可以阻止您拥有一种反射遵守访问限制的语言。这样做的问题是，调试器、分析器、覆盖工具、IntelliSense、IDE、一般工具需要能够违反访问限制。由于无法向不同的客户端呈现不同版本的反射，因此大多数语言选择工具而不是安全性。 （E 是反例，作为有意识的设计选择，它绝对没有任何反射能力。）
但是，谁说你不能向不同的客户呈现不同版本的反射？好吧，问题很简单，在反射的经典实现中，所有对象都有责任反射自身，并且由于每个对象只有一个，因此只能有反射的版本。
那么，糟糕的设计的想法从何而来？好吧，请注意上一段中的“负责任”一词。每个对象都有责任反思自身。此外，每个对象都对其最初编写的目的负责。换句话说：每个对象至少有两个职责。这违反了面向对象设计的基本原则之一：单一职责原则。
解决方案相当简单：分解对象。原始对象只负责它最初编写的目的。还有另一个对象（称为镜子，因为它是反射其他对象的对象）负责反射。既然反射的责任被分解为一个单独的对象，那么是什么阻止我们拥有不是一个、而是两个、三个、许多镜像对象呢？一种尊重访问限制，一种只允许对象反映自身而不是任何其他对象，一种只允许自省（即只读），一种只允许反映只读调用点信息（即对于一个探查器），一个提供对整个系统的完全访问权限，包括违反访问限制（对于调试器），一个仅提供对方法名称和签名的只读访问权限并遵守访问限制（对于 IntelliSense）等等
……一个不错的好处是，这意味着镜子本质上是用于反射的能力（在这个词的能力-安全意义上）。 IOW：镜像是十年来协调安全性和运行时动态元编程的圣杯。
Mirrors 的概念最初是在 Self 中发明的，后来又延续到 Animorphic Smalltalk/Strongtalk，然后是新话。有趣的是，Java 调试接口是基于镜像的，因此 Java（或者更确切地说是 JVM）的设计者清楚地了解它们，但 Java 的反射被破坏了。
No, reflection doesn't break the idea of private methods. At least not per se. There is nothing that says that reflection can't obey access restrictions.
Badly designed reflection breaks the idea of private methods, but that doesn't have anything to do with reflection per se: anything which is badly designed can break the idea of private methods. In particular, a bad design of private methods can also obviously break the idea of private methods.
What do I mean by badly designed? Well, as I said above, there is nothing stopping you from having a language in which reflection obeys access restrictions. The problem with this is that e.g. debuggers, profilers, coverage tools, IntelliSense, IDEs, tools in general need to be able to violate access restrictions. Since there is no way to present different different versions of reflection to different clients, most languages opt for tools over safety. (E is the counterexample, which has absolutely no reflective capabilities whatsoever, as a conscious design choice.)
But, who says that you cannot present different versions of reflection to different clients? Well, the problem is simply that in the classical implementation of reflection, all objects are reponsible for reflecting on themselves, and since there is only one of every object, there can be only version of reflection.
So, where does the idea of bad design come in? Well, note the word "responsible" in the above paragraph. Every object is responsible for reflecting on itself. Also, every object is responsible for whatever it is that it was written for in the first place. In other words: every object has at least two responsibilities. This violates one of the basic principles of object-oriented design: the Single Responsibility Principle.
The solution is rather simple: break up the object. The original object is simply responsible for whatever it was originally written for. And there is another object (called a Mirror because it is an object that reflects other objects) which is responsible for reflection. And now that the responsibility for reflection is broken out into a separate object, what's stopping us from having not one, but two, three, many Mirror Objects? One that respects access restrictions, one that only allows an object to reflect upon itself but not any other objects, one that only allows introspection (i.e. is read-only), one that only allows to reflect on read-only callsite information (i.e. for a profiler), one that gives full access to the entire system including violating access restrictions (for a debugger), one that only gives read-only access to the method names and signatures and respects access restrictions (for IntelliSense) and so on …
As a nice bonus, this means that Mirrors are essentially Capabilities (in the capability-security sense of the word) for reflection. IOW: Mirrors are the Holy Grail on the decade-long quest to reconcile security and runtime dynamic metaprogramming.
The concept of Mirrors was originally invented in Self from where it carried over into Animorphic Smalltalk/Strongtalk and then Newspeak. Interestingly, the Java Debugging Interface is based on Mirrors, so the designers of Java (or rather the JVM) clearly knew about them, but Java's reflection is broken.
是的，反思打破了这个想法。本机语言也有一些打破 OOP 规则的技巧，例如，在 C++ 中可以使用指针技巧来更改私有类成员。然而，通过使用这些技巧，我们得到的代码可能与未来的类版本不兼容——这就是我们为违反 OOP 规则而付出的代价。
Yes, reflection breaks this idea. Native languages also have some tricks to break OOP rules, for example, in C++ it is possible to change private class members using pointer tricks. However, by using these tricks, we get the code which can be incompatible with future class versions - this is the price we pay for breaking OOP rules.
确实如此，正如其他人已经说过的那样。
但是，我记得在 Java 中可能有一个活动的安全管理器，如果您无权这样做，它可能会阻止您访问任何私有方法，即使有反射也是如此。如果您运行本地 JVM，这样的管理器通常不活动。
It does, as other already stated.
However, I remember that in Java there can be a security manager active, that could prevent you from accessing any private methods, even with reflection, if you don't have the rights to do so. If you run your local JVM, such a manager is usually not active.
是的，反射可能被用来违反封装，甚至导致不正确的行为。请记住，需要信任程序集才能执行反射，因此仍然存在一些保护措施。
Yes, Reflection could be used to violate encapsulation and even cause incorrect behavior. Keep in mind that the assembly needs to be trusted to perform reflection, so there are still some protections in place.
是的，如果你愿意的话，它会破坏封装。然而，它可以得到很好的利用 - 比如为私有方法编写单元测试，或者有时 - 正如我从自己的经验中学到的 - 绕过第三方 API 中的错误:)
请注意，封装！=安全性。封装是一种面向对象的设计理念，只是为了改进设计。为了安全起见，有 SecurityManager 在java中。
Yes it breaks the encapsulation, if you want it to. However, it can be put to good use - like writing unit tests for private methods, or sometimes - as I have learned from my own experience - getting around bugs in third party APIs :)
Note that encapsulation != security. Encapsulation is an object oriented design concept and is only meant for improving the design. For security, there is SecurityManager in java.
是的。反射破坏了封装原则。这不仅是为了访问私有成员，而是公开类的整个结构。
Yes. Reflection breaks encapsulation principle. That's not only to get access to private members but rather expose whole structure of a class.
我认为这是一个意见问题，但如果您使用反射来绕过开发人员在类上放置的封装，那么您就达不到目的了。
因此，为了回答您的问题，它打破了封装（或信息隐藏）的概念，封装只是声明私有属性/方法是私有的，因此它们不能在类之外被破坏。
I think this is a matter of opinion, but if you are using reflection to get around the encapsulation put in place by a developer on a class, then you are defeating the purpose.
So, to answer your question, it breaks the idea of encapsulation (or information hiding), which simply states that private properties/methods are private so they cant be mucked with outside the class.
反射使任何 CLR 类都可以检查和操作其他 CLR 类的属性和字段，但不一定明智地这样做。类可以模糊属性和字段的含义，或者通过让它们以不明显的方式相互依赖、静态字段、底层操作系统信息等来保护它们免遭篡改。
例如，类可以保留某个变量其主窗口的操作系统句柄的加密版本。使用反射，另一个类可以看到该变量，但在不知道加密方法的情况下，它无法识别它所属的窗口或使该变量引用另一个窗口。
我见过一些声称充当“通用序列化器”的类；如果应用于像数据存储容器类这样缺少“可序列化”属性但在其他方面完全简单的东西，它们会非常有用。如果将它们应用于任何其创建者试图掩盖事物的类，它们将产生官样文章。
Reflection makes it possible for any CLR class to examine and manipulate properties and fields of other CLR classes, but not necessarily to do so sensibly. It's possible for a class to obscure the meaning of properties and fields or protect them against tampering by having them depend in non-obvious fashion upon each other, static fields, underlying OS info, etc.
For example, a class could keep in some variable an encrypted version of the OS handle for its main window. Using reflection, another class could see that variable, but without knowing the encryption method it could not identify the window to which it belonged or make the variable refer to another window.
I've seen classes that claim to act as "universal serializers"; they can be very useful if applied to something like a data-storage-container class which is missing a "serializable" attribute but is otherwise entirely straightforward. They will produce gobbledygook if applied to any class whose creator has endeavored to obscure things.
是的，它确实破坏了封装。但在某些情况下使用它有很多充分的理由。
例如：
我在某些网站中使用 MSCaptcha ，但它呈现 MSCaptcha分区>围绕<图像>标签弄乱了我的 HTML。然后我可以使用标准 <图像> tag 并使用反射获取验证码的图像 id 值来构造 URL。
图像 id 是私有属性，但使用反射我可以获得该值。
Yes, it does break encapsulation. But there are many good reasons to use it in some situations.
For example:
I use MSCaptcha in some websites, but it renders a < div> around the < img > tag that messes with my HTML. Then i can use a standard < img> tag and use reflection to get the value of the captcha's image id to construct a URL.
The image id is a private Property but using reflection i can get that value.
通过 private/protected/package/public 进行访问控制主要并不是为了安全。
它可以帮助好人做正确的事，但不能阻止坏人做错误的事。
一般来说，我们假设其他人都是好人，但我们却将他们的代码包含到我们的应用程序中。
如果你不能信任你所加入的图书馆的工作人员，那么你就完蛋了。
access control through private/protected/package/public is not primarily meant for security.
it helps good guys to do the right thing, but doesn't prevent bad guys from doing wrong things.
generally we assume others are good guys, and we include their code into our application without though.
if you can't trust the guy of a library you are including, you are screwed.