我刚刚用大约 12 个几乎相同的单行代码重构了一个脚本，它使用反射将静态方法动态绑定到一个类。
我的问题是：这看起来是否过度设计？我是否在追求一些实践中的学术优雅，比明显的方式更糟糕？重构后的形式更短（大约 70 行）并且更“漂亮”（对于某些定义的美的概念），但新手程序员可能根本不理解它。
问问题
131 次
5 回答
2
“幼稚”方法的一个问题是可维护性——您有 12 倍的方法来维护、调试和测试。想象一下，您需要为所有这些添加一个额外的参数......随着时间的推移，这些方法将变得非常相似但不完全相同。因此，“复杂”的方法可能会随着时间的推移而得到回报。
顺便说一句，28 种“幼稚”方法之一中存在一个错误，其余 27 种方法中都不存在 :)
于 2012-10-30T04:37:41.690 回答
1
代码应该易于阅读和编写（没有错误）。短篇易写，难懂。
如果您必须选择一个，我会选择较短的，因为它不太可能遇到错误。对它的工作方式进行大量评论，也许可以举例说明它应该返回的内容。如果可能，尽量减少重复。
于 2012-10-30T04:35:34.170 回答
1
通常我会避免回答这些问题，因为我处于您提到的新手级别的低端，但是既然您提到了它...... :)
我发现更“工程化”的版本更容易消化，特别是因为你提到的单行代码更少。理解第二个版本中发生的事情的概念飞跃只需要像我这样的人（再次，超级新手）就可以遵循，但是一旦该部分浸入，设计的相对简单/优雅（以及更明显的分组）要声明的方法的数量）远远超过任何额外的时间来理解这个概念。
再说一次，我的意见是最后一个真正重要的，但如果我发现自己在阅读别人的代码（或我自己的）并在一分钟后想“啊，现在这是做事的好方法”（而不是“好吧，现在我在写这篇文章时在想什么，它又是如何工作的？”），我觉得它在正确的位置（这是我与你的结束的地方）。
于 2012-10-30T04:48:12.213 回答
0
我的意见是，让代码尽可能简单和直接。这意味着新手和专家都应该可以理解它。
如果您的代码保持重点，即使是新手或中级程序员，也很容易修改和扩展。修改的能力发展了“解决方案”。进化的解决方案是一个好的解决方案的一个例子:-)。
顺便说一句，我认为这个问题属于Code Review.SE，但我可能是错的。
于 2012-10-30T04:25:06.070 回答
0
于 2012-10-30T04:41:43.353 回答