英文:
Is the argument of breaking SINGLETON pattern with REFLECTION practical?
问题
我了解了通过枚举实现SINGLETON，这样可以保持单例的性质，即使在反射的情况下也是如此。
在实际行业/实时情景中可能会发生这种情况吗？
我的理解是不会。
当所有的代码都在我手里时，为什么会发生这种情况呢？为任何单例类发生这种情况。
相反，这种代码实践将对那些能够访问代码存储库的人可见，所以不会被忽视！
询问是否有一些透过这可能发生的透视，以便我能够理解！
英文:
I learned about SINGLETON to be implemented through enums, so that, it retains the singleton nature against reflection also.
Can there be a practical industry/realTime scenario, where such thing could happen ?
My understanding is NO.
When all the code is with me, why will I have such a thing happen to any singleton class at my code.
Rather, such code practice, would be visible to those having access to code repository, so it wont skip the eyes !
Asking to understand, if I am missing some perspective, through which this could actually happen !
答案1
得分: 3
如果你在询问是否有可能破解以其他方式实现的单例模式，那么是的，这是可能的：
- 你可以使用反射来访问私有字段。
- 你可以使用反射来更新一个final字段。
这是否实际可行？嗯，这取决于你所说的"实际"是什么意思。
这是否可能在实践中发生？是的。
我们无法列举某人可能需要（或选择）这样做的原因。但假设你有某种紧急原因需要更改单例的值，而且你已经丢失了所有源代码。（是的，这种情况确实发生过！）或者假设你从未拥有过源代码。
当所有代码都在我手里时，为什么会在我的代码中发生这种情况。
如果你拥有源代码，并且有自由更改和重新编译源代码的权利，那么使用反射来破解单例是一个不好的主意。如果出于实际原因需要破坏单例的不变性，那么最好的做法是修改API，以便清楚地说明你在做什么以及为什么这样做。
此外，这种代码实践对于那些可以访问代码库的人来说是可见的，所以不会被忽视！
仅仅因为有人可以访问，并不意味着他们会费心查看。而且仅仅因为他们查看并不意味着他们会看到。（在应用程序代码库中隐藏执行可疑操作的代码的方法有很多。）
不管怎样，重点是这种情况对于某些版本的单例模式是可能的（对于其他版本则不是），而任何可能性如果情况允许或需要的话都可能发生。
英文:
If you are asking if it is possible to break a singleton implemented some other way, then yes it is possible:
- You can use reflection to gain access to a private field
- You can use reflection to update a final field.
Is it practical? Well it depends on what you mean by practical.
Could it happen in practice? Yes.
We cannot enumerate the reasons that someone might need (or choose) to do such a thing. But suppose that you had some pressing reason to change the value of a singleton, and you had lost all of your source code. (Yes. It happens!) Or supposed that you never had the source code in the first place.
> When all the code is with me, why will I have such a thing happen to any singleton class at my code.
If you have the source code, and the freedom to change and recompile the source code, then it would be a bad idea to break a singleton using reflection. If it is necessary (for pragmatic reasons) to break the singleton's invariants, then it is better to modify the API so that is clear what you are doing and why.
> Rather, such code practice, would be visible to those having access to code repository, so it wont skip the eyes !
Just because someone has access doesn't mean that they will bother to look. And just because they look doesn't mean they will see. (There are ways to hide code that does dubious things within an application code base.)
Anyhow, the point is that this kind of thing is possible for some versions of the singleton pattern (and not others) and anything that is possible could happen if the circumstances allowed or required it.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论