架构，许多方法与长参数列表

Question

我们正努力在三层架构的情况下尽可能清晰，干净地做事。

但是我们系统的复杂性使我们对最佳的继续方式感到困惑。

如果我们使用大量功能链通过服务层，使用较小的参数列表，这似乎在做什么的方面很明显，但感觉很多功能正在这些方法中重复。

但是，如果我们使用较少的方法，并且有大量的参数列表来改变方法中的功能，那么这似乎已经失控了。

我们目前的选择是拥有更多的功能，因为这比其中包含大量逻辑流的单片函数更容易管理。这显然意味着更小的可管理代码块。

我们只是听说过DRY很多，所以感觉这些方法内部会有一些重复。但似乎更灵活。

Answer 1

我认为最好提供两个你的意思的例子。 这听起来像是以下之一：

1. 你的设计很差。
2. 您通过许多对象展开了互动/行为。
3. 您正在错误地使用DI \ design模式。
4. 您的代码实际上是程序性的而不是OO。

因为您没有提供任何示例，所以我会在短期内完成所有这些选项。

<强> 1。你的设计很糟糕。

第3。您错误地使用了DI \ design模式。

也许你应该以不同方式分割你的代码，也许你应该使用DI或重温你如何使用它。也许您应该应用一些设计模式来使问题易于管理。

<强> 2。您可以通过许多对象展开互动/行为。 考虑使用DCI http://alexsmail.blogspot.com/2012/09/dci.html来解决这个问题。

<强> 4。您的代码实际上是程序性的而不是OO。 我看到程序员用Java编写的代码经常编写程序代码。它有许多 tweak 方法执行的参数。解决方案是重新设计代码并（重新）训练程序员。

Answer 2

大多数人喜欢较小的方法签名而不是大签名。它使得更容易推理方法（更不用说测试它们了！），但是你不应该用它来证明违反DRY原则的行为。

您是否有任何理由不能使用小方法签名并将常用的复制代码分解为内部帮助程序方法？

Answer 3

我真的相信，对于企业应用程序而言，没有什么比一个好的分层架构更好了，有良好的意图揭示类和方法的名称，以及在整个解决方案中应用的一些设计模式。 按照这个规则，有很长的方法是矛盾的，因为他们可能会违反单一责任原则，所以他们不会用他们的名字来表达他们真正在做什么。如果您想使用DRY原则，只需保持方法和类的清洁，简洁和清晰，并应用一些设计模式，以便在整个解决方案中重用它们。

我建议阅读Domain Driven Desing（Eric Evans）和Clean Code（Robert C. Martin），详细了解这种“代码哲学”。

Answer 4

我假设“许多方法”执行相同的功能，唯一不同的是参数。

我的apporach将使用一些对象传递数据，类似于将参数传递给GridBagLayout对象中的GridBagConstraints的方式。例如，对于搜索查询，我传递一个具有所有可能条件的bean“Filter”，该方法中的代码是延长但不复杂的（“条件X指定 - >添加X过滤器以查询”）并且可以很容易分为几个辅助函数。

Answer 5

这通常是强耦合应用程序的症状。要从A到B，你需要转十五回合然后再回过头来。

减少耦合的一个好方法是引入域事件。例如，当创建用户时，您将在课程UserCreated和SendWelcomeEmail或NotifyAdminsOfNewUser

订阅时生成名为SendIntroductionaryOffer的域事件

重点是，任何人都可以采取行动，有效降低复杂性，因为您不必再​​强烈关联代码了。