分模块开发

分模块开发设计

按照功能拆分

我们自己写的项目基本上都是在一个模块中，这个模块拥有:
配置类config，实体类pojo，服务类service，数据库访问类dao，前端控制类controller，自定义异常类exception等。
显得十分的臃肿，且不便于维护。虽然这样做功能也都实现了，但是也存在了一些问题，我们拿银行的项目为例来聊聊这个事。

• 网络没有那么发达的时候，我们需要到银行柜台或者取款机进行业务操作
• 随着互联网的发展,我们有了电脑以后，就可以在网页上登录银行网站使用U盾进行业务操作
• 再来就是随着智能手机的普及，我们只需要用手机登录APP就可以进行业务操作

上面三个场景出现的时间是不相同的，如果非要把三个场景的模块代码放入到一个项目，那么当其中某一个模块代码出现问题，就会导致整个项目无法正常启动，从而导致银行的多个业务都无法正常办理。所以我们会按照功能将项目进行拆分。

按照模块拆分

比如电商的项目中，有订单和商品两个模块，订单中需要包含商品的详细信息，所以需要商品的模型类，商品模块也会用到商品的模型类，这个时候如果两个模块中都写模型类，就会出现重复代码，后期的维护成本就比较高。我们就想能不能将它们公共的部分抽取成一个独立的模块，其他模块要想使用可以像添加第三方jar包依赖一样来使用我们自己抽取的模块，这样就解决了代码重复的问题,这种拆分方式就说我们所说的按照模块拆分。

经过案例的分析，我们就知道:

• 将原始模块按照功能拆分成若干个子模块，方便模块间的相互调用，接口共享。

可以将domain层也就是pojo进行拆分，除了domain层，我们也可以将其他的层也拆成一个个对立的模块，如:

这样的话，项目中的每一层都可以单独维护，也可以很方便的被别人使用。关于分模块开发的意义，我们就说完了，说了这么多好处，那么该如何实现呢?

分模块开发实现

我们准备了以下这个标准的Java项目，可以看到它十分完整

抽取domain层（pojo层）

步骤1:创建新模块

创建一个名称为maven_03_pojo的jar项目,为什么项目名是从02到03这样创建，原因后面我们会提到，这块的名称可以任意。

步骤2:项目中创建domain包

在maven_03_pojo项目中创建top.yn.domain包，并将maven_02_ssm中Book类拷贝到该包中。

步骤3:删除原项目中的domain包

删除后，maven_02_ssm项目中用到Book的类中都会有红色提示，如下:

说明:出错的原因是maven_02_ssm中已经将Book类删除，所以该项目找不到Book类，所以报错。

要想解决上述问题，我们需要在maven_02_ssm中添加maven_03_pojo的依赖。

步骤4:建立依赖关系

在maven_02_ssm项目的pom.xml添加maven_03_pojo的依赖

<dependency>
    <groupId>top.yn</groupId>
    <artifactId>maven_03_pojo</artifactId>
    <version>1.0-SNAPSHOT</version>
</dependency>

看起来就像我们之前用pom添加第三方依赖一样，组名-包名-版本号，一应俱全。

因为添加了依赖，所以在maven_02_ssm中就已经能找到Book类，所以刚才的报红提示就会消失。

步骤5:编译maven_02_ssm项目

编译maven_02_ssm你会在控制台看到如下错误:

错误信息为：不能解决maven_02_ssm项目的依赖问题，找不到maven_03_pojo这个Jar包。
原因是Maven会从本地仓库找对应的Jar包，但是本地仓库又不存在该Jar包所以会报错。
在IDEA中是有maven_03_pojo这个项目，所以我们只需要将maven_03_pojo项目安装到本地仓库即可。

步骤6:将项目安装本地仓库

将需要被依赖的项目maven_03_pojo，使用maven的install命令，把其安装到Maven的本地仓库中。

安装成功后，在对应的路径下就看到安装好的Jar包

说明:具体安装在哪里，和你们自己电脑上Maven的本地仓库配置的位置有关。

当再次执行maven_02_ssm的compile的命令后，就已经能够成功编译。

依赖管理

我们现在已经能把项目拆分成一个个独立的模块，当在其他项目中想要使用独立出来的这些模块，只需要在其pom.xml使用<dependency>标签来进行Jar包的引入即可。
<dependency>其实就是依赖，关于依赖管理里面都涉及哪些内容，我们就一个个来学习下:

• 依赖传递
• 可选依赖
• 排除依赖

我们先来说说什么是依赖:
依赖指当前项目运行所需的Jar，一个项目可以设置多个依赖。
格式为:

<!--设置当前项目所依赖的所有jar-->
<dependencies>
    <!--设置具体的依赖-->
    <dependency>
        <!--依赖所属群组id-->
        <groupId>org.springframework</groupId>
        <!--依赖所属项目id-->
        <artifactId>spring-webmvc</artifactId>
        <!--依赖版本号-->
        <version>5.2.10.RELEASE</version>
    </dependency>
</dependencies>

依赖传递与冲突问题

回到我们刚才的项目案例中，打开Maven的面板，你会发现:

在项目所依赖的这些jar包中，有一个比较大的区别就是有的依赖前面有箭头>,有的依赖前面没有。

那么这个箭头所代表的含义是什么?

打开前面的箭头，你会发现这个jar包下面还包含有其他的jar包

你会发现有两个maven_03_pojo的依赖被加载到Dependencies中，那么maven_04_dao中的maven_03_pojo能不能使用呢?

要想验证非常简单，只需要把maven_02_ssm项目中pom.xml关于maven_03_pojo的依赖注释或删除掉。

• 在Dependencies中移除自己所添加maven_03_pojo依赖后，打开BookServiceImpl的类，你会发现Book类依然存在，可以被正常使用

这个特性其实就是我们要讲解的依赖传递。
依赖是具有传递性的:

说明:A代表自己的项目；B,C,D,E,F,G代表的是项目所依赖的jar包；D1和D2、E1和E2代表是相同jar包的不同版本
(1) A依赖了B和C,B和C有分别依赖了其他jar包，所以在A项目中就可以使用上面所有jar包，这就是所说的依赖传递
(2) 依赖传递有直接依赖和间接依赖

• 相对于A来说，A直接依赖B和C,间接依赖了D1,E1,G，F,D2和E2
• 相对于B来说，B直接依赖了D1和E1,间接依赖了G
• 直接依赖和间接依赖是一个相对的概念

(3)因为有依赖传递的存在，就会导致jar包在依赖的过程中出现冲突问题，具体什么是冲突?Maven是如何解决冲突的?

这里所说的依赖冲突是指项目依赖的某一个jar包，有多个不同的版本，因而造成类包版本冲突。
情况一: 在maven_02_ssm的pom.xml中添加两个不同版本的Junit依赖:

<dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.12</version>
      <scope>test</scope>
    </dependency>
  
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.11</version>
      <scope>test</scope>
    </dependency>
</dependencies>

通过对比，会发现一个结论

• 特殊优先：当同级配置了相同资源的不同版本，后配置的覆盖先配置的。

情况二: 路径优先：当依赖中出现相同的资源时，层级越深，优先级越低，层级越浅，优先级越高

• A通过B间接依赖到E1
• A通过C间接依赖到E2
• A就会间接依赖到E1和E2,Maven会按照层级来选择，E1是2度，E2是3度，所以最终会选择E1

情况三: 声明优先：当资源在相同层级被依赖时，配置顺序靠前的覆盖配置顺序靠后的

• A通过B间接依赖到D1
• A通过C间接依赖到D2
• D1和D2都是两度，这个时候就不能按照层级来选择，需要按照声明来，谁先声明用谁，也就是说B在C之前声明，这个时候使用的是D1，反之则为D2

但是对应上面这些结果，大家不需要刻意去记它。因为不管Maven怎么选，最终的结果都会在Maven的Dependencies面板中展示出来，展示的是哪个版本，也就是说它选择的就是哪个版本，如:

如果想更全面的查看Maven中各个坐标的依赖关系，可以点击Maven面板中的show Dependencies

在这个视图中就能很明显的展示出jar包之间的相互依赖关系。

可选依赖和排除依赖

依赖传递介绍完以后，我们来思考一个问题，

• maven_02_ssm 依赖了 maven_04_dao
• maven_04_dao 依赖了 maven_03_pojo
• 因为现在有依赖传递，所以maven_02_ssm能够使用到maven_03_pojo的内容

如果说现在不想让maven_02_ssm依赖到maven_03_pojo，有哪些解决方案?

说明:在真实使用的过程中，maven_02_ssm中是需要用到maven_03_pojo的，我们这里只是用这个例子描述我们的需求。因为有时候，maven_04_dao出于某些因素的考虑，就是不想让别人使用自己所依赖的maven_03_pojo。

方案一:可选依赖

• 可选依赖指对外隐藏当前所依赖的资源—不透明

在maven_04_dao的pom.xml,在引入maven_03_pojo的时候，添加optional。

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>maven_03_pojo</artifactId>
    <version>1.0-SNAPSHOT</version>
    <!--可选依赖是隐藏当前工程所依赖的资源，隐藏后对应资源将不具有依赖传递-->
    <optional>true</optional>
</dependency>

此时BookServiceImpl就已经报错了,说明由于maven_04_dao将maven_03_pojo设置成可选依赖，导致maven_02_ssm无法引用到maven_03_pojo中的内容，导致Book类找不到。

方案二:排除依赖

• 排除依赖指主动断开依赖的资源，被排除的资源无需指定版本—不需要

前面我们已经通过可选依赖实现了阻断maven_03_pojo的依赖传递，对于排除依赖，则指的是已经有依赖的事实，也就是说maven_02_ssm项目中已经通过依赖传递用到了maven_03_pojo，此时我们需要做的是将其进行排除，所以接下来需要修改maven_02_ssm的pom.xml。

<dependency>
    <groupId>com.itheima</groupId>
    <artifactId>maven_04_dao</artifactId>
    <version>1.0-SNAPSHOT</version>
    <!--排除依赖是隐藏当前资源对应的依赖关系-->
    <exclusions>
        <exclusion>
            <groupId>com.itheima</groupId>
            <artifactId>maven_03_pojo</artifactId>
        </exclusion>
    </exclusions>
</dependency>

这样操作后，BookServiceImpl中的Book类一样也会报错。

当然exclusions标签带s说明我们是可以依次排除多个依赖到的jar包，比如maven_04_dao中有依赖junit和mybatis,我们也可以一并将其排除。

介绍我这两种方式后，简单来梳理下，就是

• A依赖B,B依赖C,C通过依赖传递会被A使用到，现在要想办法让A不去依赖C
• 可选依赖是在B上设置<optional>,A不知道有C的存在，
• 排除依赖是在A上设置<exclusions>,A知道有C的存在，主动将其排除掉。

聚合和继承

未完待续。。。。。