搜索和调用带有反射的方法的开销

如果您希望获得良好的性能,反射会带来很大的开销。如果您的例程(消息分派)将被反复使用,那么多态性替代方案会更好。另外,在我看来,从面向对象的角度来看会更好,因为 Brian

您处理30+条消息的CLA可以很容易地增长到100+条消息,然后您将拥有一个包含100+个方法的类,同时添加私有方法,代码重用将非常困难,您的类将变得一团糟。

多态性和切换上的反射开销如下所示:

time spent on a switch case call: 1
time spent on a polymorphism call: 1.1
time spent on a reflection call: 1.9-2.0

您可以将process方法添加到枚举中。

大开关(每种情况都只调用一个方法)到底有什么问题?

反射的主要代价是它会使代码变得很糟糕

我会让语言和OO系统为您工作,并使用适当的方法实现创建一个接口/抽象基类。

Knuth )

支配

您描述的第二种模式基本上包括一个包含30多个方法的类,对吗?随着时间的推移,这将是一个相当痛苦的问题。