何时反射不再值得?(这是一个提问标题,无需回答)

5

我刚刚将一个包含十几个几乎相同的一行代码的脚本重构为使用反射绑定静态方法到类的动态脚本。

重构后的版本在这里重构前在这里

我的问题是:这样看起来过度设计了吗?我是否在追求某些学术优雅,实际上比明显的方式更糟糕?重构后的形式要短得多(约70行),更“美观”(对于某种定义的美学概念),但初学者可能完全不理解。


2
你可能想要修复那些链接并使它们永久可用(使用完整的哈希值而不是分支名称)以供将来参考。 - poke
@poke 完成。感谢您提出。 - yarian
5个回答

2

“幼稚”的方法存在一个问题,那就是可维护性——您需要维护、调试和测试多达12倍的方法。想象一下,如果您需要向它们中的所有方法添加一个额外的参数……随着时间的推移,这些方法将变得非常相似,但不完全相同。因此,“复杂”的方法可能会在未来发挥作用。

顺便说一下,在28种“幼稚”方法中有一个bug,而其他27种方法则没有这个bug :)


哈哈哈,当我重构代码时,我注意到了这个 bug。这几乎是建议使用非 naive 的方法了吧 :) - yarian

1

代码应该易于阅读和编写(无错误)。短的代码容易编写,但难以理解。

如果必须选择一个,我会选择更短的代码,因为它不太可能出现错误。对其工作原理进行详细注释,最好附带返回值示例。如果可能,尽量减少重复。


1
通常我会避免回答这些问题,因为我处于你提到的初学者水平的较低端,但既然你提到了... :)
我发现更“工程化”的版本更容易理解,特别是因为它有更少的你提到的一行代码。对于像我这样的人(再次强调,超级新手),理解第二个版本中正在发生的事情所需的概念跨度只需要一点时间,但是一旦这部分被吸收,相对简单/优雅的设计(以及更可见的方法分组)远远超过了理解概念所需的任何额外时间。
再次强调,我的意见是真正重要的最后一个意见,但如果我发现自己阅读别人的代码(或自己的代码)并且在一分钟后想“啊,现在这是一个好方法”(而不是“好吧,当我写这个时我在想什么,它又是如何工作的?”),我感觉它处于正确的位置(这就是我在你的代码上结束的地方)。

0

我的看法是尽可能保持代码的简单和直接性。这意味着即使对于新手和专家都能理解。

如果您的代码保持"简洁明了",甚至新手或中级程序员也可以轻松修改和扩展。修改的能力促进了"解决方案"的演变。演化的解决方案是一个好的例子:-)。

顺便说一句,我认为这个问题应该放在 Code Review.SE 上,但我可能错了。


我很难为这个选择一个家。我不认为它完全适合代码审查,因为我并不是真正寻求有关整个代码的反馈,而是关于其特定反射使用的反馈。但我也可能错了。感谢您告诉我代码审查的存在! - yarian

0

                                  Simplicty and elegance must be balanced with productivity and practice.


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接