java架构到底是做什么的，一段对话让你懂( 二 ) _java

文章插图

老鸟：下面是接收者代码：

文章插图

老鸟：可以看到，接收者代码依赖了发送者代码，也就是说SpecificReceiver依赖了Sender 。同时可以看到，发送者代码对接收者代码一无所知。
菜鸟：哈，你作弊了。你把接收者的接口放到了发送者的类里了。
老鸟：你开始明白了。
菜鸟：明白什么？
老鸟：当然是架构原则啊。发送者持有接收者必须实现的接口。
菜鸟：如果这意味着我要使用内部类，那么……
老鸟：使用内部类只是方法之一，还有其它的方法。
菜鸟：请等一下。最开始我们讨论的是数据库，那这些跟数据库又有什么关系呢？

文章插图

老鸟：让我们来看一下其它代码吧。首先是一个简单的业务逻辑

文章插图

菜鸟：这个业务逻辑没有做什么事情啊。

老鸟：这只是个例子。在实际实现业务逻辑的时候，不会有很多类似这样的类的。
菜鸟：好吧。那么Gateway是用来做什么的呢？

老鸟：它为业务逻辑提供了所有访问数据的方法。下面是它的代码：

文章插图

老鸟：要注意，这个接口是在businessRules包里面的。
菜鸟：好吧。那Something这个类又是用来做什么的呢？

老鸟：它代表一个简单的业务对象。我把它放在另一个叫entities的包里。

文章插图

老鸟：最后需要实现BusinessRuleGateway接口，这个实现类会知道相关的数据库细节：

文章插图

老鸟：可以看到，业务逻辑是在运行时对数据库进行调用的。而在编译时，是database包引用了businessRules包。
菜鸟：好吧，我想我明白了。你用多态性隐藏了数据库实现。不过在业务逻辑里，仍然引用了数据库的工具接口。
老鸟：不，不是这样的。我们并没有打算为业务逻辑提供所有的数据库工具接口，而是业务逻辑创建了它们所需要的接口。在实现这些接口的时候，可以调用相应的工具。
菜鸟：嗯，这样的话，如果业务逻辑需要所有的工具，那么你必须把所有工具都放到Gateway接口里。
老鸟：哈，我觉得你还是没有明白。
菜鸟：不明白什么？我觉得已经很清楚了。
老鸟：每个业务逻辑只定义它所需要的接口。
菜鸟：等等，什么意思？
老鸟：这个叫作接口分离原则。每个业务逻辑只使用一部分数据库工具，所以每个业务逻辑只定义能够满足需要的接口。
菜鸟：这样的话，你就会有很多接口，而且有很多实现类。
老鸟：哈，是的。你开始明白了。
菜鸟：这样子很浪费时间！我为什么要这样做呢？
老鸟：这样做是为了让代码更干净，并且节省时间。
菜鸟：算了吧，这样只会增加更多的代码。
老鸟：相反，这其实是很重要的架构决定，这跟你之前所说的那些所谓的重要决定是不一样的。
菜鸟：什么意思？
老鸟：还记得你刚开始说你要成为一个软件架构师吗？你还想要做所有重要的决定？
菜鸟：是啊，我是这么想过。
老鸟：你想做所有关于数据库、Web服务和框架的决定。
菜鸟：是啊，而你却说它们都不重要，还说它们其实跟重要的决定不相干。
老鸟：没错，它们确实跟重要的决定不相干。一个软件架构师真正要做的重要决定都在数据库、Web服务器和框架之外。
菜鸟：但首先要先决定用什么数据库、Web服务器或框架啊！
老鸟：实际上应该在开发后期才开始做这些事情——在你掌握了更多信息之后。
老鸟：当架构师草率地决定要使用一个数据库，后来却发现使用文件系统效率更高。
老鸟：当架构师草率的决定使用一个Web服务器，后来却发现团队需要的不过是一个socket接口。
老鸟：当架构师草率地决定使用一个框架，后来却发现框架提供的功能是团队不需要的，反而给团队带来了诸多约束。
老鸟：当架构师在掌握了足够多的信息后才决定该用什么数据库、Web服务器或框架。