Chr*_*rry 5 language-agnostic architecture
我们正努力在三层体系结构的情况下尽可能清晰,干净地做事.
但是我们系统的复杂性使我们对最佳的进展方式感到困惑.
如果我们使用大量功能链通过服务层,使用较小的参数列表,这似乎在做什么的方面很明显,但感觉很多功能正在这些方法中重复.
但是,如果我们使用较少的方法,并且有大量的参数列表来改变方法中的功能,那么这似乎已经失控了.
我们目前的选择是具有更多的功能,因为这比其中内部有大量逻辑流的单片函数更容易管理.这显然意味着更小的可管理代码块.
我们只是听说DRY很多,所以感觉这些方法内部会有一些重复.但似乎更灵活.
大多数人更喜欢较小的方法签名而不是大的方法签名。它使推理方法变得更加容易（更不用说测试它们了！），但是您不应该用它来证明违反 DRY 原则的合理性。
是否有任何原因导致您不能使用小方法签名并将常见的复制代码分解到内部辅助方法中？