对象关联和依赖分析

       讨论这个题目，是最近项目中遇到的一个需求让我联想到了这些内容，下面会有所说明。

 

       依赖是对象之间关联最弱的一种关系，关联交依赖稍强。为了尽量的降低对象之间的耦合度我们推荐依赖而少用关联。具体的表现形式为：方法中的参数为依赖，而对象中的引用为关联。

 

       下面我们结合分层来讨论下关联。我们应该将关联定义到那一层。控制层，还是模型层，模型层细分我们可以定义出业务逻辑层和数据库交互层。从解耦的角度考虑，关联越少越好，但是实际的项目中总免不了关联。从关联的角度考虑好像解决不了问题，因为我们的确需要关联，那么就从内聚的角度考虑。比如Service层（业务逻辑层）其职责就是负责具体的业务操作，其直接操作的对象应该是JavaBean,并且该JavaBean是同业务相关的，对于其它的对象我们一定不要关联进来，除非有一些公用的算法，或者是静态的类需要使用。这时你可能会说业务逻辑层最终还是要跟数据库打交道，总不能在视图层或者控制层做数据库的操作，这点我们要首肯，业务逻辑层只能和数据库层的对象关联。因为我们要依赖数据，此时另一个问题出来了，数据库的连接从哪里来？如果是使用Hibernate那么Session从哪里来？抽象，将连接的获取单独的抽出来，已被大家共同使用。这样设计出来的类，我们只会看到其只负责具体的业务，跟其它对象八竿子打不到，这样的话我们的类就可以独立使用了，无论放到哪里都不会受其它对象的影响。耦合内聚同时满足。

 

        解决了Service的关联处理，现在说控制层，控制层有一个调度员的职责，它可以同各层的对象来交互，做为一个汇总和调度。这样也是合理的，因为我们说了Service只处理与其相关的JavaBean，我们调用某个方法返回的可能就是JavaBean对象相关的数据结构，但是它并不适用视图层，怎么办，此时应该是控制层来调用视图层的方法来得到其想要的Model对象，此时会出现视图层和JavaBean产生了联系，但是大家可以看到它们之间的联系仅仅存在依赖关联这是是最弱的联系，这是被允许的。当拿到Model对象后，控制层负责将其交给页面之类的视图来做展现。由此我们可以说让控制层来调度而不是互相关联。

 

       以此我们得到如下的结论，控制层负责调度，视图层负责页面展示信息的处理，业务逻辑层负责具体的业务，数据库层负责同数据库的交互，这样就各司其职互不干扰，无论那一层单独使用都不会有问题，并且每一层的修改也不会导致其它层的改变，只是我们的控制器要做少量或不用改动。

 

       说下项目中的需求，在每一个模块都会有一个过滤树来做为查询的过滤条件，但是有一个模块需要在树上附加一些其它信息，这些信息对其它模块来说是不需要的，之前的设计是我们的控制层都调用同一段逻辑来生成过滤树，这本身就是好的，但是导致其它模块会出现不想要的信息。原因在于我们的抽象不够，对于过滤树来说其应该是一个更加抽象的对象，因为大家都需要并且这棵树很干净。因此解决的办法只能是将过滤树抽象为一个抽象对象专门负责生成一颗干净的树，每一个模块应该有专门负责生成树的对象，该对象继承这个抽象类，这样我们在不同的模块调用不同的方法就可以避免上述的问题。

 

       总结来说，抽象，接口，无论什么时候都要先提取出来，以此为基来扩展实现，并且实现要做到高内聚低耦合。