个人总结之jar包依赖和耦合

前言

　　最近在接触新项目的时候，发现了一个小问题，我们先看下下面这张图：

　　问题描述：在我的服务中引用了一个jar包，而这个jar中通过远程调用其他服务，但是改jar包本身没有读取RPC配置，需要在我的服务中为该jar包配置。通常对于我的服务来说，引用jar包对于其他服务的远程调用应该是透明的，如下图所示：

　　到此，问题就产生了，我的服务到底应不应该为jar包配置RPC信息？我们先来从代码角度分类一下jar包。

1、完全体jar包

　　此类jar包仅仅是java封装的一个体现，内部实现了一系列共用的方法，有自己独立的功能，换句话说就是该jar包帮你写了你想用的代码，如jdk自带的类都可以归为此类，只不过jdk自带的类不需要你手动引用而已

2、入侵式jar包

　　此类jar包需要使用者去完善其中的某些信息，进而完成某一系列的功能，如数据库连接的jar包，需要使用者配置连接池的信息等；再比如spring的JdbcTemplate，抛出一个PreparedStatementCreator接口，让使用者通过实现类去完成SQL的参数绑定。这类jar包是java多态的一个表现，也可以理解成设计模式中的模板方法模式。

3、规范系jar包

　　此类jar包只是一些列的模型和接口的定义，在面向服务编程的时代，任何服务的实现都不会直接暴露给使用者，取而代之的就是规范系的jar包，符合面向接口编程的规范

结论

　　根据实际jar的情况进行选择，第一类jar包不在我们的考虑范围；对于第二类jar包，我们则需要进行配置；但对于第三类jar包，每个服务应该都自己独立的体系，各个服务直接耦合性很低，彼此直接不应该有任何相关联的配置。如果我引用的jar包是第二类，那么我需要为其配置RPC信息，否则不要为它擦屁股！