模式背后的事情

如果只单纯的从程序设计的角度去理解模式是不够的。
有时候看看那些封装,抽象和接口定义很容易有一个想法 – 何必呢。大师都说这是为了解耦,因为软件管理终归是依赖的管理,模式的背后同样是为了更好的管理依赖。

依赖管理的好坏从模块之间的划分就可以看出,最终的好处体现在开发,测试以及最后的整合的简化。从软件工程的角度可以很容易的体会出依赖管理的重要性。

说说抽象工厂模式,最常用的就是DAOFactory,可以有很多方法创建各种DAO对象。例如

DaoFactoryIF{
UserDaoIF getUserDao();
MemberDaoIF getMemberDao();
}

DaoFactoryImpl{
UserDaoIF userDao;
MemberDaoIF memberDao;
UserDaoIF getUserDao(){return userDao;}
MemberDaoIF getMemberDao(){return memberDao;}
//setters
}

DaoFactoryImpl通过类似spring这样的框架的帮助下注入所有的依赖,即真正的UserDaoIF,MemberDaoIF的实现。
这样的好处是什么呢?从DaoFactoryImpl这个类看,它并没有依赖任何具体实现。在发布时,所有的接口被发布为inf.jar,而各种实现 impl1.jar,impl2.jar…则是都只依赖于inf.jar。常见的错误做法是做成all.jar,也就是不管3721发布到一起,这么做也不能说绝对的不好,但如果要更大程度上的复用,避免局部的copy/paste,还是要把依赖划分的清楚一点,虽然这样做要求一些集成(integration)的能力。

Comments are closed.