使用反射被认为是unOOPish？

Question

使用反射有什么风险？它以任何方式违背OOP吗？

我开始在C＃项目中轻松使用它，现在我发现它在许多场景中都很实用。

谢谢。

Answer 1

OOP是一种技术和结构，而不是宗教。

你不会因为没有在你的项目中使用它而犯罪。如果你知道更好的方法，那就去吧。明智地使用反射可以为您节省很多复杂性。

确保它干净可读，这样你的队友就不会把你钉在十字架上。反思是强大的，但强大的力量带来了巨大的责任等等。

Answer 2

回答标题中的问题：不，不是先验。例如，当实现工厂来创建不同（但相关）类型的对象时，反射可以非常方便。

但是，这些都是实现细节，通常应隐藏在通用接口后面。反思也往往很慢，因此不鼓励过度使用。基本上，当没有其他（好）解决方案时，使用它，而不是其他地方。

一般来说，OOP并不真正与反思竞争。但是当OOP足够时，不要尝试使用反射来实现动态调度或侦听/回调。

Answer 3

Reflection可以打破封装并在类和另一个类的内部实现之间创建耦合。错误地使用它会导致糟糕的OO设计，但这与不面向对象不同。在某些方面，它也可以用来实现传统OO代码遇到问题的东西，比如AOP（面向方面​​编程）。纯粹主义者可能会将此视为非OOP，但我认为这是一种超集关系。

有些地方我发现反射很方便：

• 单元测试，访问内部状态以设置或验证数据
• 属性，包括访问属性值和从属性
访问对象属性
• 属性验证 - 为各种属性类型编写常用验证器
• 使用/转换匿名类型

除了单元测试之外，我通常只反思公共属性/方法，以免破坏封装并创建与内部实现的耦合。

Answer 4

像Smalltalk这样的普通OO语言有反射。使用它的人会考虑没有它的语言几乎无法使用。能够在运行时推理程序对于大型系统至关重要。

Answer 5

这取决于你在反思中所做的事情......我已经使用它来枚举公共API，并在Java中（通过内省库）使用JavaBeans做有用的事情。仔细地使用它非常有用。

我认为问题不一定在您开始使用反射时出现，而是在您使用它来破坏封装时 - 在对象内窥视以观察和修改隐藏的内部状态。除非你小心，否则紧密耦合和脆弱性会在封装破坏后迅速传播到你的类中。

Answer 6

所有OO编程语言都支持更小或更大程度的反射。有些人鼓励使用它（例如Smalltalk，在频谱的一端），有些人则不鼓励它（例如C ++，另一方面）。使用这两种语言来实现你每天使用的软件的相对频率可能会告诉你一些关于大量使用反射的可取性。

请注意，这不是一场语言大战的尝试 - 我实际上是一个Smalltalk粉丝＆amp;打算今天晚上做一些Squeaking。

Answer 7

任何时候接口只是没有为你切割它，我可能会反对，也许是因为一个无法预料的变化，或者因为事情太复杂而无法严格指定。请记住，像Python这样的语言中的鸭子类型是通过反射来实现的。你只能按名称使用一种方法，它既可以工作也可以抛出。我将反射看作是在静态类型语言中打字的后门。恕我直言，除非你认为鸭子打字从根本上是错误的并且永远不会使用它，否则反射没有任何问题，只要有问题的代码不是性能关键的。