5

我们正在尝试在 3 层架构的情况下尽可能清晰和干净地做事。

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

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

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

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

只是我们经常听到有关 DRY 的消息，所以感觉方法内部有一些重复。但它似乎更灵活。

4

5 回答 5

2

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

  1. 你的设计很糟糕。
  2. 您的交互/行为分布在许多对象中。
  3. 您错误地使用了 DI\design 模式。
  4. 您的代码实际上是程序性的，而不是面向对象的。

因为您没有提供任何示例，所以我将简要介绍所有这些选项。

1. 你的设计不好。

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

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

2. 你的交互/行为分布在许多对象中。 考虑使用 DCI http://alexsmail.blogspot.com/2012/09/dci.html来解决这个问题。

4. 你的代码实际上是程序性的，而不是面向对象的。 我看到程序员用 Java 编写的代码经常编写程序代码。它有许多调整方法执行的参数。解决方案将是重新设计您的代码并（重新）培训您的程序员。

于 2012-09-23T17:23:06.703 回答
1

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

我建议阅读领域驱动设计 (Eric Evans) 和清洁代码 (Robert C. Martin) 以详细了解这种“代码哲学”。

于 2012-09-20T16:05:32.267 回答
1

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

有什么理由不能有小的方法签名并将常见的复制代码分解到内部帮助方法中？

于 2012-09-20T15:58:15.240 回答
0

这通常是强耦合应用程序的症状。要从 A 到 B，您必须转十五圈，然后再往回走。

减少耦合的一个好方法是引入领域事件。例如，当创建用户时，您将生成一个名为UserCreatedwhen 的域事件，该事件被该类订阅SendWelcomeEmail，NotifyAdminsOfNewUser或者SendIntroductionaryOffer

关键是任何人都可以对事件采取行动，这有效地降低了复杂性，因为您不必再​​强耦合您的代码。

于 2012-09-21T10:20:03.100 回答
0

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

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

于 2012-09-20T16:02:09.857 回答