转自: http://www.cnblogs.com/justinw/archive/2006/11/28/574573.html
开篇-模式和原则
前言
园子里已经有好几位大侠和前辈写过设计模式系列的文章了,我从他们那曾经吸收了太多的精华,大恩不言谢,我这里还是谢过了。
提纲
设计模式介绍
模式:每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的解决方案的核心。
[说到这里,有必要声明一下的是,在该系列文章中,凡提到模式,都是指软件行业的基于GOF的《设计模式:可复用面向对象软件的基础》一书的面向对象设计模式,GRASP模式除外。]
比设计模式更重要:GRASP (职责分配原则)
例如:常见的网上商店里的购物车(ShopCar),需要让每种商品(SKU)只在购物车内出现一次,购买相同商品,只需要更新商品的数量即可。如下图:
针对这个问题需要权衡的是,比较商品是否相同的方法需要放到那里类里来实现呢?分析业务得知需要根据商品的编号(SKUID)来唯一区分商品,而商品编号是唯一存在于商品类里的,所以根据信息专家模式,应该把比较商品是否相同的方法放在商品类里。
实际应用中,符合下列任一条件的时候,都应该由类A来创建类B,这时A是B的创建者:
例如:因为订单(Order)是商品(SKU)的容器,所以应该由订单来创建商品。如下图:
这里因为订单是商品的容器,也只有订单持有初始化商品的信息,所以这个耦合关系是正确的且没办法避免的,所以由订单来创建商品。
意思就是说,不需要通信的两个对象之间,不要进行无谓的连接,连接了就有可能产生问题,不连接就一了百了啦!
b. 如果A已经和B有连接,如果分配A的职责给B不合适的话(违反信息专家模式),那么就把B的职责分配给A。
c. 两个不同模块的内部类之间不能直接连接,否则必招报应!嘿!
这里我们在订单类里增加了一个TotalPrice()方法来执行计算总价的职责,没有增加不必要的耦合。
高内聚的意思是给类尽量分配内聚的职责,也可以说成是功能性内聚的职责。即功能性紧密相关的职责应该放在一个类里,并共同完成有限的功能,那么就是高内聚合。这样更有利于类的理解和重用,也便于类的维护。
例如:一个订单数据存取类(OrderDAO),订单即可以保存为Excel模式,也可以保存到数据库中;那么,不同的职责最好由不同的类来实现,这样才是高内聚的设计,如下图:
这里我们把两种不同的数据存储功能分别放在了两个类里来实现,这样如果未来保存到Excel的功能发生错误,那么就去检查OrderDAOExcel类就可以了,这样也使系统更模块化,方便划分任务,比如这两个类就可以分配个不同的人同时进行开发,这样也提高了团队协作和开发进度。
用来接收和处理系统事件的职责,一般应该分配给一个能够代表整个系统的类,这样的类通常被命名为“XX处理器”、“XX协调器”或者“XX会话”。
关于这个模式更详细的论述,请参考《UML和模式应用》第16章。
这样的设计更符合高内聚和低耦合原则,虽然后来我们又增加了一个菱形(Diamond)类,对整个系统结构也没有任何影响,只要增加一个继承Shape的类就行了。
例如:上面多态模式的例子,如果我们的绘图程序需要支持不同的系统,那么因为不同系统的API结构不同,绘图功能也需要不同的实现方式,那么该如何设计更合适呢?如下图:
这里我们可以看到,因为增加了纯虚构类AbstractShape,不论是哪个系统都可以通过AbstractShape类来绘制图形,我们即没有降低原来的内聚性,也没有增加过多的耦合,可谓鱼肉和熊掌兼得,哈哈哈!
9. Protected Variations (受保护变化)
比设计模式更重要:设计原则
对于设计原则的深入探讨我还没有那个深度,推荐大家去看《敏捷软件开发—原则、模式与实践》,下面仅对部分常用的设计原则做些简单的讲解:
那么我们该怎么做呢?如下图,将不同的职责分配给不同的类,使单个类的职责尽量单一,就隔离了变化,这样他们也不会互相影响了。
2. 开放—封闭原则(OCP)
那么我们该如何来设计一个通用的开关呢?参考下图的设计,OK!现在我们不仅可以打开灯,还可以打开电视和音响,甚至未来任何实现了“开关接口”的任何东西。
4. 接口隔离原则(ISP)
那么我们该如何解决这个问题呢?参考下图的设计,为每个类都单独设计专门的操作接口,使得它们只依赖于它们关系的方法,这样就不会互相影响,也就不会在发生土鳖的事情了! 5. 替换原则(LSP)
“子类型必须能够替换掉它们的基类型。”也就是说继承中的“IS A”关系是必须保证的,否则还算什么继承啊!如果违反了LSP原则,常会导致在运行时(RTTI)的类型判断违反OCP原则。
例如:函数A的参数是基类型,调用时传递的对象是子类型,正常情况下,增加子类型都不会影响到函数A的,如果违反了LSP,则函数A必须小心的判断传进来的具体类型,否则就会出错,这就已经违反了OCP原则。
关于模式学习
模式跟OO原则相比其实并不重要,如果你能设计出基本符合以上原则的程序,那么可能就已经总结出了新的模式,所以学习模式的根本是为了深入理解OO思想和原则,使我们可以写出高内聚低耦合的程序。
作者
Mail:xiaoliang.justin@gmail.com