了解此架构答案

【问题标题】：Understanding this architecture了解此架构
【发布时间】：2011-09-02 13:27:03
【问题描述】：

我从我的前任那里继承了一个庞大的系统，我开始了解它是如何工作的，但我不明白为什么。

它在 java 中并使用接口，应该添加一个额外的层，但它们添加了 5 或 6。

当按下用户界面按钮并调用一个看起来像这样的函数时，它是这样的

foo.create(stuff...)
{
    bar.create;
}

bar.create 完全相同，只是它调用foobar.creat，然后又调用barfoo.create。在找到访问数据库的函数之前，它会遍历 9 个类。

据我所知，每个额外的函数调用都会产生更多的性能成本，所以这对我来说似乎很愚蠢。

同样在foo.create 中，所有变量都经过错误检查，这是有道理的，但在其他所有调用中，错误检查都会再次发生，看起来就像剪切和粘贴代码。这似乎很疯狂，因为一旦检查了变量就不需要重新检查，因为在我看来这只是浪费处理器周期。

这是我第一个使用 java 和接口的项目，所以我只是对发生的事情感到困惑。

谁能解释为什么系统会这样设计，它有什么好处/缺点，如果它不好我可以做些什么来改进它？

谢谢。

【问题讨论】：

根据您的描述，这听起来像是界面矫枉过正。但是，如果不仔细查看所有代码，很难确定这是一个问题。如果某些方法只是“通过”，而其他方法在调用链中实现得更快，那么这种布局仍然有意义。但是，多级错误检查可能不是一个好主意，除非它们在生产中被关闭。
有没有可能问问做这件事的人？也许他可以给你一些解释或提示。
@Paul W 他们都只是通过，没有早下车。您认为可以将初始调用更改为更远的地方以跳过一些但仍然使用主界面吗？
@aav 我所得到的只是转到此函数中的这一行并更改此变量，对于它的工作方式非常缺乏创意。
@Skeith 那么，该说什么.. 如果您必须在很长一段时间内“使用”该软件并对其进行维护-也许您应该开始考虑（和计划）简化的可能方法它（清理、重构、消除不必要的复杂性）

【解决方案1】：

我建议您查看设计模式，看看它们是否正在项目中使用。最初搜索像 factory 和 abstract factory 这样的词。只有这样，才能正确理解先前开发者的意图。

此外，一般而言，除非您在资源受限的设备上运行，否则不必担心额外调用的成本或间接级别。如果它有助于您的设计，使其更易于理解或对扩展开放，那么额外的调用是值得的。

但是，如果代码中有复制粘贴，那就不是一个好兆头，开发人员可能不知道自己在做什么。

【讨论】：

我担心四核服务器上的额外调用可能需要 20 分钟才能使按钮单击生效。
不需要的 CPU 周期并不是唯一的额外成本。有时没有充分理由的不必要的复杂性甚至更糟。
@Skeith - 尽管您所描述的内容听起来很可疑，但多次调用不会导致这种降级，除非它们都进行了一些广泛的处理。如果您尝试解决性能问题，请分析代码并查看它的实际位置。
@Robin 我认为存在性能问题。 @Skeith 无法弄清楚如何管理系统并浪费时间挖掘代码。这也是一个性能问题。

【解决方案2】：

很难理解您的软件到底做了什么。也许它甚至是有道理的。但我见过一些“设计模式狂人”完成的几个项目。看起来他们想展示他们对各种委托、间接等方面的知识。也许是你的情况。

【讨论】：

【解决方案3】：

如果不仔细检查架构，我无法评论架构，但一般来说，跨不同层分离服务是一个好主意。这样，如果您更改一项服务的实现，其他服务将保持不变。但是，只有在不同层之间存在松散耦合时才会如此。

此外，通常每个服务都处理与其提供的服务类型特别相关的异常，而将其余的留给其他服务。这也让我们可以减少服务层之间的耦合。

【讨论】：