c# - 合并编码风格 : Funcs, 私有(private)方法，单一方法类

Question

我们目前有 3 个开发人员，其中一些开发人员的风格相互冲突，我正在寻找一种方法来为王国带来和平...

程序员:

Foo 1:喜欢使用 Func 和 Action 的内部公共(public)方法。他使用 actions 来避免冗长的方法调用，并使用 Func 来执行简单的任务，这些任务可以用 1 或 2 行来表达，并且将在整个代码中频繁使用

优点:他的代码主体简洁且可读性强，通常每个类只有一两个公共(public)方法，很少有私有(private)方法。

缺点:方法的开头包含其他开发人员不喜欢阅读的富含 lambda 的代码块；有时，可以包含其他开发人员真的不喜欢阅读的高阶函数。

---

Foo 2:喜欢为(几乎)公共(public)方法必须做的所有事情创建一个私有(private)方法。

优点:公共(public)方法仍然很小且可读(对所有开发人员而言)。

缺点:私有(private)方法很多。使用调用其他私有(private)方法的私有(private)方法，调用...等等，等等。使代码难以导航。

---

Foo 3: 喜欢为每个需要执行的重要任务创建一个带有单一公共(public)方法的公共(public)类，然后将它们依赖注入(inject)到其他对象中。

优点:易于测试、易于理解(一个对象，一项责任)。

缺点:项目中充满了类，打开多个类文件以了解代码的作用会使导航变得笨拙。

---

如果能够充分利用所有这些技术，那就太好了……

Foo-1 有非常好的、可读的(几乎是类似 dsl 的)代码……在大多数情况下，除了在方法开始时聚集在一起的所有 Action 和 Func lambda 恶作剧。

Foo-3 具有高度可测试和可扩展的代码，对于某些解决方案来说感觉有点“束缚”并且有一些代码导航问题(在 VS 中不断按 F12 并打开其他 5 个 .cs 文件以找出单一方法的作用)。

还有 Foo-2...嗯，我不确定我是否喜欢这个包含 2 个公共(public)方法和 12 个私有(private)方法的巨大 .cs 文件，除了它更容易让初学者深入研究这一事实。

我承认我过度简化了对这些编码风格的解释；但如果有人知道任何模式、实践或外交策略可以帮助我们的三个开发人员团结起来(而不只是告诉他们中的任何一个“停止它!”)，那就太好了。

从可行性的角度来看:

• 由于一些开发人员发现 lambda 和/或 Func 难以阅读，Foo-1 的风格遇到了最大的阻力。
• Foo-2 的风格遇到的阻力较小，因为它很容易陷入。
• Foo-3 的风格需要最具前瞻性的思考，时间紧迫时难以执行。

有什么关于一些编码风格或惯例的想法可以使这项工作成功吗？

Answer 1

完全不清楚您为什么不喜欢 Foo-2 的私有(private)方法。

您提示“巨大”的 .cs 文件 - 但为什么它会比 Foo-1 的样式大得多？那里有相同数量的代码，只是操作被拆分为方法而不是表示为 lambda。

老实说，Foo-2 对我来说似乎是最好的选择。将您的公共(public) API 保持在您希望公开的范围内，然后以最简单的方式实现它。虽然 lambda 在某些情况下绝对适用，但 Foo-1 的风格听起来像是把它发挥到了极致——超出了它真正合理的范围。

尤其要考虑您的两个公共(public)方法是否有一些共同的子任务。 Foo-1 的方法最终会复制该代码 - Foo-2 的方法会将公共(public)代码放在一个从两者调用的私有(private)方法中……这对我来说似乎是一种明智的方法。

同样，您谈论的是调用私有(private)方法的私有(private)方法……当然等效的 Foo-1 代码将是调用 lambda 表达式的 lambda 表达式，这几乎没有任何改善!

此外，如果您对白盒单元测试感到满意，Foo-2 的方法可以通过单独测试实现的“较小”位来更轻松地测试“笨拙”的公共(public) API 实现 - 诚然迫使您使用方法的内部可见性而不是私有(private)的，或使用反射。

Foo-3 听起来完全是一种不同的方法，因为它改变了公共(public) API 而不是实现。这更多的是关于设计而不是编码风格，应该单独考虑。