mvn 模块化 公共依赖_创建无依赖性的真正模块化代码

mvn 模块化 公共依赖

情况变得更糟。 您开始发现应用程序中的多个错误。 通常，解决一个错误会创建两个新错误。 此时，您可以开始唱歌：

代码中的99个小错误。
99个小错误。
放下一个，修补一下，

…代码中的127个小错误。

您现在对这个项目的工作感觉如何如果您像我一样，您可能会开始失去动力。 开发此应用程序只是一件痛苦的事情，因为对现有代码的每次更改都可能带来不可预测的后果。

这种经验在软件界很常见，可以解释为什么这么多的程序员想要扔掉源代码并重写所有内容。

软件开发随着时间推移而变慢的原因

那么，这个问题的原因是什么呢

主要原因是复杂性增加。 根据我的经验，整体复杂性的最大贡献者是这样一个事实，即在绝大多数软件项目中，所有事物都是相互联系的。 由于每个类都具有依赖性，因此，如果您在该类中更改了一些发送电子邮件的代码，则您的用户突然无法注册。 这是为什么因为您的注册代码取决于发送电子邮件的代码。 现在，如果不引入错误，您将无法进行任何更改。 根本不可能跟踪所有依赖项。

所以你有它; 问题的真正原因是由于代码具有的所有依赖关系而导致了复杂性的提高。

大泥球及其减少方法

有趣的是，这个问题已经有很多年了。 这是一种常见的反模式，称为“大泥巴”。 多年来，我在多个不同公司从事的几乎所有项目中都看到过这种架构。

那么，这种反模式到底是什么呢简而言之，当每个元素与其他元素有依赖关系时，您将陷入困境。 在下面，您可以看到著名的开源项目Apache Hadoop的依赖关系图。 为了可视化大泥球（或更确切地说，大纱球），您绘制了一个圆并将项目中的类均匀地放置在其上。 只需在相互依赖的每对类之间画一条线。 现在您可以看到问题的根源。

上面组件中的每个元素都可以由一个单独的公司提供，该公司对最终产品或其其他零件一无所知。 只要每个模块化元素都是根据规格制造的，您就可以按计划创建最终设备。

我们可以在软件行业复制吗

我们当然可以！ 通过使用接口和反转控制原理； 最好的部分是，这种方法可以在任何面向对象的语言中使用：Java，C＃，Swift，TypeScript，JavaScript，PHP —清单不胜枚举。 您不需要任何精美的框架即可应用此方法。 您只需要遵守一些简单的规则并保持纪律。

控制反转是你的朋友

当我第一次听说控制反转时，我立即意识到找到了解决方案。 这是获取现有依赖关系并使用接口对其进行反转的概念。 接口是方法的简单声明。 他们没有提供任何具体的实现。 结果，它们可以用作两个元素之间如何连接它们的协议。 如果愿意，它们可以用作模块化连接器。 只要一个元素提供接口，另一个元素提供接口的实现，它们就可以一起工作，而彼此之间却一无所知。 这个棒极了。

让我们看一个简单的示例，如何将系统解耦以创建模块化代码。 下图已实现为简单的Java应用程序。 您可以在此GitHub存储库中找到它们。

问题

假设我们有一个非常简单的应用程序，仅由类，三个服务和单个类组成。 这些元素以多种方式相互依赖。 在下面，您可以看到使用“大泥巴”方法的实现。 类之间相互简单地调用。 它们紧密耦合，您不能简单地去除一个要素而不碰其他要素。 使用此样式创建的应用程序使您可以快速成长。 我相信这种风格适用于概念验证项目，因为您可以轻松地玩转事物。 但是，它不适合用于生产就绪的解决方案，因为即使维护也很危险，并且任何单个更改都可能产生无法预测的错误。 下图显示了这个泥浆建筑的大球。

当前情况和一大堆麻烦之间的唯一区别是，现在，我们不是直接调用类，而是通过它们的接口来调用它们。 它稍微改善了彼此分离的元素。 例如，如果您想在另一个项目中重用 ，则可以通过取出本身以及 ， 和 。 如您所见， 仍然取决于其他元素。 结果，我们仍然遇到在一个地方更改代码而在另一个地方弄乱行为的问题。 它仍然会产生一个问题，即如果您修改和 ，则需要更改所有依赖于它的元素。 这种方法并不能解决任何问题。 在我看来，它只是在元素之上添加了一层接口。 您永远不应注入任何依赖关系，而应该一劳永逸地摆脱它们。 为独立而欢呼！

模块化代码的解决方案

我认为，解决所有依赖关系的所有主要问题的方法是完全不使用依赖关系。 您创建一个组件及其侦听器。 侦听器是一个简单的界面。 每当需要从当前元素外部调用方法时，只需将方法添加到侦听器并改为调用它即可。 该元素仅允许使用文件，其包内的调用方法以及使用主框架或其他使用的库提供的类。 在下面，您可以看到将应用程序修改为使用元素架构的图表。

显然，您最终需要为元素增加更多的复杂性，但是您可以轻松地做到这一点。 只要确保您的逻辑类都不依赖项目中的其他文件即可。 他们只能在此元素中使用主框架，导入的库和其他文件。 对于图像，视图，声音等资产文件，还应将其封装在元素中，以便将来可以轻松重用。 您只需将整个文件夹复制到另一个项目中就可以了！

在下面，您可以看到显示更高级元素的示例图。 注意，它包含正在使用的视图，并且不依赖于其他任何应用程序文件。 如果您想知道一种检查依赖关系的简单方法，只需查看导入部分。 当前元素之外是否有文件如果是这样，则需要通过将这些依赖关系移到元素中或向侦听器添加适当的调用来删除这些依赖关系。

让我们看一个用Java创建的简单“ Hello World”示例。

最初，我们定义来指定打印输出的方法。 元素本身在下面定义。 在元素上调用时，它仅使用打印一条消息。 请注意，该元素完全独立于方法的实现。 可以将其打印到控制台，物理打印机或精美的UI中。 该元素不依赖于该实现。 由于这种抽象，该元素可以轻松地在不同的应用程序中重用。

现在看看主要的类。 它实现了侦听器，并将元素与具体实现组合在一起。 现在我们可以开始使用它了。

您也可以在JavaScript中运行此示例

元素架构

让我们看一下在大型应用程序中使用元素模式。 在一个小型项目中展示它是一回事，将其应用于现实世界则是另一回事。

我喜欢使用的全栈Web应用程序的结构如下所示：

在源代码文件夹中，我们最初将客户端文件和服务器文件分开。 这样做是合理的，因为它们在两种不同的环境中运行：浏览器和后端服务器。

然后，我们将每一层中的代码分成名为app和elements的文件夹。 元素由具有独立组件的文件夹组成，而app文件夹将所有元素连接在一起并存储所有业务逻辑。

这样，可以在不同项目之间重用元素，而所有特定于应用程序的复杂性都封装在一个文件夹中，并且通常减少为对元素的简单调用。

动手实例

相信实践总是胜过理论，让我们看一下在Node.js和TypeScript中创建的真实示例。

现实生活中的例子

这是一个非常简单的Web应用程序，可以用作更高级解决方案的起点。 它的确遵循元素架构，并且使用了广泛的结构元素模式。

从高亮显示，您可以看到主页已被区分为一个元素。 此页面包含其自己的视图。 因此，例如，当您要重用它时，您可以简单地复制整个文件夹并将其放入另一个项目中。 只需将所有内容连接在一起，就可以设置好了。

这是一个基本示例，说明您可以立即在自己的应用程序中引入元素。 您可以开始区分独立的组件并分离其逻辑。 您当前正在处理的代码有多混乱都没有关系。

开发更快，经常重用！

我希望，通过这套新工具，您将能够更轻松地开发可维护性更高的代码。 在实际使用元素模式之前，让我们快速回顾一下所有要点：

• 由于多个组件之间的依赖关系，导致软件中出现许多问题。
• 通过在一处进行更改，您可以在其他地方引入不可预测的行为。

三种常见的体系结构方法是：

• 大泥球。 这对于快速发展非常有用，但是对于稳定生产而言却不是那么重要。
• 依赖注入。 您应该避免这种半生不熟的解决方案。
• 元素架构。 该解决方案使您可以创建独立的组件，并在其他项目中重复使用它们。 它具有可维护性和出色的性能，可以稳定地发布产品。

基本元素模式包括一个具有所有主要方法的主类以及一个侦听器，该侦听器是一个简单的接口，可以与外部世界进行通信。

为了实现全栈元素架构，首先需要将前端代码与后端代码分开。 然后在每个应用程序和元素中创建一个文件夹。 elements文件夹由所有独立元素组成，而app文件夹则将所有内容连接在一起。

现在，您可以开始创建和共享自己的元素。 从长远来看，它将帮助您创建易于维护的产品。 祝你好运，让我知道你创造了什么！

翻译自: https://hackernoon.com/creating-truly-modular-code-with-no-dependencies-16f8f784d4a6

mvn 模块化 公共依赖

相关资源：渣浆泵的计算机选型软件及应用.rar-制造文档类资源-CSDN文库