java 代码模块化_关于Java：如何使代码模块化？

我有一些Java程序，现在我想弄清楚它是否是模块化的，如果它是模块化的，那么要扩展到什么程度，因为模块化永远不能是二进制术语，即0或1。

我如何确定特定的代码在很大程度上达到了模块化。 我想知道如何使代码更具模块化吗？

如果代码是真正的模块化，则每个组件都应该是一个黑匣子。 知识组件之间相互了解的越少，系统的模块化程度就越高。

模块化的一些基准：

您要重写几次类似的代码来执行特定任务？

万一您在程序的某个部分中进行了某些更改，您需要重构多少代码？

文件更小且更易于浏览吗？

应用程序模块是否在需要时充分且独立地执行？

您的代码灾难性如何？当您仅删除一个函数或变量时，所有地狱破坏都会消失吗？重命名课程时会出现20多个错误吗？ (对于实例，您可以实现堆栈机制以跟踪应用程序中的所有跃点)

代码与自然语言用法的距离有多近(即模块及其子组件代表了更多实际对象，而无需过多关注净源文件的大小)。

有关更多想法，请查看此内容以及有关软件质量的内容

至于您对使代码更具模块化的关注，您应该问自己上述问题，为他们获取具体答案，然后再看一下

基本原理是将您的应用程序分解为尽可能小的代码片段，这些代码片段应整齐地排列在许多易于理解和可访问的目录布局中。

应用程序中的每种方法所进行的处理都不得超过所需的最小处理量。将这些方法组合到越来越多的宏级别方法中，应带您回到应用程序

另一个基准可能是"删除标准"：如果从程序中删除X(包，类，方法，字段)，会有什么坏处？ 如果有休息，它们与已删除项目有多远？ 如果损坏的物品很远，则意味着X的模块化程度较低。

(添加到以前的注释中)-删除某些内容时，您立即将其与程序的其余部分(所有与调用代码连接的位置)的连接公开。 更高的模块化通常意味着更少的连接点，并且通常意味着这些连接点在范围上更"本地"(例如，在单个程序包中)。

+1！ 完全正确！

尽管确实确实部分地考虑了重构，部分地对模块进行了独立测试，但单独提及它仍然没有害处！

不幸的是，"签出"链接断开了。

重点是

关注点分离

凝聚

封装(通过接口进行通信)

可替代性

可重用性

这种模块系统的一个很好的例子是标准的汽车零件，例如盘式制动器和汽车音响。

在构建汽车时，您不想从头开始构建汽车音响。您宁愿购买并插入。您也不希望制动系统影响汽车立体声系统-或更糟糕的汽车立体声系统影响制动系统。

要回答您的问题，"我如何才能确定特定代码在很大程度上达到模块化"，我们可以提出问题来测试模块化。您可以在不影响应用程序其他部分的情况下轻松地用其他模块替换模块吗？

XML解析器可能是另一个示例。一旦获得DOM接口，您实际上就不在乎在下面使用哪种XML解析器实现(例如Apache Xerces或JAXP)。

在Java中，另一个问题可能是：是否可以通过interface访问所有功能？接口几乎可以解决低耦合问题。

另外，您能否用一句话描述系统中的每个模块？例如，汽车立体声系统播放音乐和广播。盘式制动器使车辆安全减速。

(这是我写的什么是组件驱动的开发？)

根据Wikipedia所说，基于组件的开发是基于组件的软件工程(CBSE)的别名。

[It] is a branch of software

engineering, the priority of which is

the separation of concerns in respect

of the wide-ranging functionality

available throughout a given software

system.

这有些含糊，所以让我们看一下更多细节。

An individual component is a software

package, or a module, that

encapsulates a set of related

functions (or data).

All system processes are placed into

separate components so that all of the

data and functions inside each

component are semantically related

(just as with the contents of

classes). Because of this principle,

it is often said that components are

modular and cohesive.

因此，根据此定义，一个组件可以是任何东西，只要它确实做得很好并且只能做一件事情。

With regards to system-wide

co-ordination, components communicate

with each other via interfaces. [...]

This principle results in components referred to as encapsulated.

因此，这听起来越来越像我们对好的API或SOA的看法。

提供的接口由棒棒糖表示，所需的接口由连接到UML中组件外部边缘的开放套接字符号表示。

Another important attribute of

components is that they are

substitutable, so that a component

could be replaced by another (at

design time or run-time), if the

requirements of the initial component

(expressed via the interfaces) are met

by the successor component.

Reusability is an important

characteristic of a high quality

software component. A software

component should be designed and

implemented so that it can be reused

in many different programs.

可替代性和可重用性是使组件成为组件的原因。

那么，这与面向对象编程之间有何区别？

The idea in object-oriented

programming (OOP) is that software

should be written according to a

mental model of the actual or imagined

objects it represents. [...]

Component-based software engineering,

by contrast, makes no such

assumptions, and instead states that

software should be developed by gluing

prefabricated components together much

like in the field of electronics or

mechanics.

为了回答有关如何使代码更具模块化的特定问题，有两种方法：

模块化的最佳工具之一是发现代码重用。如果您发现自己的代码在多个位置执行相同(或非常相似)的操作，那么它是模块化的理想选择。

从某种意义上说，确定其他逻辑可以独立使用，而其他逻辑可以使用它们而无需知道它们是如何构建的。尽管在OO中，模块/组件不一定需要与建模对象相对应，但这有点类似于OO设计中的对象。

HEJ，

请参见此处的"如何封装软件(第1部分)"：

http://www.edmundkirwan.com/encap/overview/paper7.html

问候，

埃德。

由于已将其标记为" osgi"，因此我可以提出与OSGi相关的观点。

简短的答案是，可以从完整的意大利面条式代码逐步转换为模块化的代码；不一定是大爆炸。例如，即使是意大利面条代码也依赖于某种形式的博洛尼亚语日志记录库，因此从某种意义上讲，它已经是模块化的，只是其中包含一个非常大的Metball(对不起，模块)。

诀窍是将大肉丸切成较小的块，然后将大肉丸切成较小的块，然后递归。也不是一done而就。每次只需稍微削一点，直到没有多余的东西要清除为止。

至于OSGi，仍然有可能将uber-jar放入捆绑包中。实际上，您可以在不更改位的情况下执行此操作。通过修改Manifest.MF或将其包装在另一个JAR中并在清单中指定Bundle-ClassPath：metaball.jar。

否则，BND之类的工具可以帮助您生成所需的正确数据，然后可以轻松地将其放入OSGi运行时中。但是要当心过度耦合的代码，以及那些与类加载器混为一谈的东西-这些会使您绊倒。

按功能打包的想法有助于使代码更具模块化。

在网络上看到的许多示例首先将应用程序划分为层，而不是功能

楷模

资料存取

用户界面

但是，最好使用与功能(而不是层次)保持一致的顶级程序包来划分应用程序。

这是使用按功能打包的Web应用程序的示例。请注意顶级程序包的名称，这些名称将作为应用程序中实际功能的列表读取。还要注意每个包如何包含与功能有关的所有项目-这些项目不会散布到整个地方。在大多数情况下，它们都位于单个包/目录中。

通常，删除此类应用程序中的功能可以通过单个操作-删除单个目录来实现。

您可以使用诸如CAP之类的代码分析工具来分析类型和包之间的依赖关系。它们将帮助您查找和删除任何循环依赖性，这在尝试开发模块化代码时通常是一个问题。

如果没有循环依赖性，则可以开始将代码分离到离散的jar中。

通常，如果可能的话，最好对接口进行编码，这通常意味着可以更轻松地在不同的上下文中重构和/或使用您的代码。

依赖注入框架(例如Spring)也可以帮助设计的模块化。当类型通过某些外部配置过程注入了它们的依赖关系时，它们不需要直接依赖于实现。

模块化与谁在开发代码有关。但我认为，普遍的共识是，模块化代码是具有易于替换而无需更改大多数原始代码的部分的代码。

恕我直言，如果您有3个模块A B和C，并且您想完全更改或替换模块C，如果这样做很简单，那么您就有了模块化代码。

正如您所说的，模块化不是二进制的东西，因此它取决于您的相对定义。

我会说：您可以在需要执行该功能的任何程序中使用给定方法吗？是您不需要知道引擎盖在做什么的"黑匣子"吗？如果答案是否定的，即该方法只能在该程序中正常工作，则它不是真正的模块化。

假设我理解您的问题，那么您想知道是什么使代码模块化，因为代码模块显然需要彼此之间有某种依赖性才能完全正常工作。这是我的答案：

如果您可以将系统分解为模块，并且可以单独测试这些模块，则可以很好地表明系统是模块化的。