【maven实战】08-可选依赖

最新推荐文章于 2023-02-02 14:09:08 发布

一直不懂

最新推荐文章于 2023-02-02 14:09:08 发布

阅读量411

点赞数

分类专栏： maven实战

maven实战专栏收录该内容

46 篇文章

订阅专栏

本文探讨了项目间的依赖关系，特别是可选依赖的概念及其在实际应用中的意义。通过一个具体例子，解释了如何设置和理解可选依赖，并讨论了为什么有时候需要它们以及它们与面向对象设计中的单一职责原则之间的关系。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

假设有这样一个依赖关系，项目A 依赖于项目B，项目B依赖于项目X和Y，B对于X和Y的依赖都是可选依赖:A->B,B->X(可选),B->Y(可选)。根据传递性依赖的定义，如果所有这三个的范围都是compile那么X，Y就是A的compile范围传递性依赖。然而由于这里X，Y是可选依赖，依赖将不会得以传递。换句话说，X，Y将不会对A有任何影响。

为什么要使用可选依赖这一特性呢？可能项目B实现了两个特性，其一依赖于X，其二依赖于Y，而且这两个特性是互斥的用户不可能同时使用两个特性。比如B是一个持久层隔离数据包，它支持多种数据库，包括MySQL，PostgreSQL等，在构建这个工具包的时候，需要这两种数据库的驱动程序，但在使用这个工具包的时候，只会依赖一种数据库。

<project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.learn.mvn</groupId>
 <artifactId>project-b</artifactId>
 <version>1.0.0</version>
 <dependencies>
  <dependency>
   <groupId>mysql</groupId>
   <artifactId>mysql-connector-java</artifactId>
   <version>5.1.10</version>
   <optional>true</optional>
  </dependency>
  <dependency>
   <groupId>postgresql</groupId>
   <artifactId>postgresql</artifactId>
   <version>8.4-701.jdbc3</version>
   <optional>true</optional>
  </dependency>
 </dependencies>
</project>
 <modelVersion>4.0.0</modelVersion>
 <groupId>com.learn.mvn</groupId>
 <artifactId>project-b</artifactId>
 <version>1.0.0</version>
 <dependencies>
  <dependency>
   <groupId>mysql</groupId>
   <artifactId>mysql-connector-java</artifactId>
   <version>5.1.10</version>
   <optional>true</optional>
  </dependency>
  <dependency>
   <groupId>postgresql</groupId>
   <artifactId>postgresql</artifactId>
   <version>8.4-701.jdbc3</version>
   <optional>true</optional>
  </dependency>
 </dependencies>
</project>

上述代码中，使用<optional>元素表示mysql和postgresql这两个依赖为可选依赖，他们只会对当前项目B产生影响，当其他项目依赖于B的时候这两个依赖不会被传递。因此当项目A依赖项目B的时候如果其实际使用基于MySQL数据库那么在项目A中就需要显示地声明mysql这一依赖。

最后关于可选依赖需要说明的一点是在理想的情况下是不应该用可选依赖的。前面我们可以看到，使用可选依赖的原因是某一个项目实现了多个特性，在面向对象设计中有个单一职责原则，意指一个类应该只有一项职责而不是糅合太多的功能。