Architecture 体系结构、大量方法与长参数列表

我们正试图在3层架构的情况下尽可能清晰、干净地完成工作

但是，我们系统的复杂性让我们对最好的方法感到困惑

如果我们在服务层中使用大量的函数链，并使用较小的参数列表，那么就所做的事情而言，这似乎很清楚，但在这些方法中似乎有很多功能在重复

但是，如果我们使用较少的方法，并且有大量的参数列表来更改方法中的功能，那么这似乎是无法控制的

我们目前的选择是拥有更多的功能，因为这比内部有大量逻辑流的单片功能更易于管理。这显然意味着更小的代码块更易于管理

---

只是我们经常听说DRY，所以感觉在方法中有一些重复。但它似乎更灵活。

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

有什么原因不能使用小方法签名并将常见的复制代码分解为内部帮助器方法吗？

我假设“很多方法”都具有相同的功能，唯一不同的是参数

---

我的方法是用几个对象传递数据，类似于在

GridBagConstraints

对象中如何将参数传递给

GridBagLayout

。例如，对于一个搜索查询，我传递了一个包含所有可能条件的bean“Filter”，方法中的代码很长，但并不复杂（“是否指定了条件X->addx Filter to query”）并且可以很容易地划分为几个辅助功能。

我真的相信，对于企业应用程序来说，没有什么比良好的分层体系结构更好的了，它具有良好的意图，显示类和方法的名称，以及在整个解决方案中应用的一些设计模式。 遵循这条规则，使用长方法是矛盾的，因为他们可能会违反单一责任原则，所以他们不会用自己的名字来表达他们真正在做什么。如果您想使用DRY原则，只需保持方法和类干净、简短和清晰，并应用一些设计模式在整个解决方案中重用它们

---

我建议阅读领域驱动的设计（Eric Evans）和干净的代码（Robert C.Martin）来详细了解这种“代码系统学”。

这通常是强耦合应用程序的症状。要从A到B，你必须先转15圈，然后再往回走一点

减少耦合的一个好方法是引入域事件。例如，创建用户时，当类

SendWelcomeEmail

和

NotifyAdminsOfNewUser

或

SendIntroductionaryOffer订阅时，您将生成名为
UserCreated
的域事件

关键是，任何人都可以对一个事件采取行动，从而有效地降低复杂性，因为您不再需要对代码进行强耦合。
我认为最好提供两个示例来说明您的意思。
听起来像是以下其中之一：

你的设计很糟糕
您的交互/行为通过许多对象展开
您正在错误地使用DI\设计模式
您的代码实际上是过程性的，而不是面向对象的
因为您没有提供任何示例，我将很快介绍所有这些选项

1。你的设计很糟糕。

3。您使用的DI\设计模式不正确。

也许你应该以不同的方式划分你的代码，也许你应该使用DI或者重新审视你是如何使用它的。也许您应该应用一些设计模式来管理问题

2。您的互动/行为通过许多对象展开。
考虑使用DCI来解决这个问题。

4。您的代码实际上是过程性的，而不是面向对象的。
我看到程序员经常用Java编写程序代码。它有许多参数来调整方法的执行。解决方案是重新设计代码并（重新）培训程序员。
如果没有更具体的例子来说明您的意思，很难回答这个问题。将重复提取到单独的方法中？这意味着我们有web层、域层和数据库层。而DI正在被使用。因此，从技术上讲，这是一个良好的实践，但在实现方面有一定的开销。我觉得这是相关的，因为开销意味着我们必须编写更多的代码来浏览每一层，这意味着许多函数或许多参数之间的开销更强烈。如果您可以发布一个示例（即使是伪代码）…数据传输对象是否有帮助，还是这只会让“汤”这个词变得更糟o） 谢谢你的介绍。您所述的任何选项都可能是正确的。我们将在执行过程中进行重构。但我认为我们通常会保留许多小函数，当你说你的代码是过程性的而不是面向对象的时。什么意思？当然所有的OO代码都有一些过程代码？我们有数据库对象、域对象、视图模型、助手类、服务、接口和存储库。这是否意味着我们已经使用了足够的OO？根据上面的描述，我认为您没有最后一个问题。：-）所有OO代码都有一些过程代码。我的意思是，我只是看到了用Java编写的过程代码，没有服务、接口等：-）虽然这里的其他答案很好，但这就是我要寻找的答案。