设计模式——概述

设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、保证代码可靠性。毫无疑问,设计模式于己于他人于系统都是多赢的,设计模式使代码编制真正工程化,可以称得上是软件工程的基石。

GoF的“设计模式”是第一次将设计模式提升到理论高度,并将之规范化,本书提出了23种基本设计模式,自此,在可复用面向对象软件的发展过程中,新的大量的设计模式不断出现。

项目中合理的运用设计模式可以完美的解决很多问题,每种模式现在都有相应的原理来与之对应,每一个模式描述了一个在我们周围不断重复发生的问题,以及该问题的核心解决方案,这也是它能被广泛应用的原因。

一、设计模式和框架

现在,可复用面向对象软件系统现在一般划分为三大类:应用程序工具箱和框架(Framework),我们平时开发的具体软件都是应用程序;JavaAPI属于工具箱;而框架是构成一类特定软件可复用设计的一组相互协作的类。

框架通常定义了应用体系的整体结构类和对象的关系等等设计参数,以便于具体应用实现者能集中精力于应用本身的特定细节。框架主要记录软件应用中共同的设计决策,框架强调设计复用,因此框架设计中必然要使用设计模式.

另外,设计模式有助于对框架结构的理解,成熟的框架通常使用了多种设计模式,如果你熟悉这些设计模式,毫无疑问,你将迅速掌握框架的结构,我们一般开发者如果突然接触EJB等框架,会觉得特别难学,难掌握,那么转而先掌握设计模式,无疑是给了你剖析EJB的一把利器。

二、设计模式的原则

近年来,大家都开始注意设计模式。那么,到底我们为什么要用设计模式呢?这么多设计模式为什么要这么设计呢?根本原因是为了代码复用,增加可维护性。那么怎么才能实现代码复用呢?OO界有前辈的几个原则:“开-闭”原则(Open Closed Principal)、里氏代换原则、合成复用原则。设计模式就是实现了这些原则,从而达到了代码复用、增加可维护性的目的。

1、“开-闭”原则

此原则是由“Bertrand Meyer”提出的。原文是:“Software entities should be open for extension,but closed for modification”。就是说模块应对扩展开放,而对修改关闭。模块应尽量在不修改原(是“原”,指原来的代码)代码的情况下进行扩展。那么怎么扩展呢?我们看工厂模式“factory pattern”:假设中关村有一个卖盗版盘的小子,我们给他设计一“光盘销售管理软件”。我们应该先设计一“光盘”接口。而盗版软件和盗版电影是其子类。小子通过“DiscFactory”来管理这些光盘。代码为:

public class DiscFactory{

public static 光盘 getDisc(String name){

return (光盘)Class.forName(name).getInstance();

}

}

有人要买盗版软件,怎么实现呢?

public class 小子{

public static void main(String[] args){

光盘 d=DiscFactory.getDisc("盗版软件");

光盘.();

}

}

如果有一天,这小子良心发现了,开始卖正版软件。没关系,我们只要再创建一个“光盘”的子类“正版软件”就可以了。不需要修改原结构和代码。怎么样?对扩展开发,对修改关闭,“开-闭原则”。

工厂模式是对具体产品进行扩展,有的项目可能需要更多的扩展性,要对这个“工厂”也进行扩展,那就成了“抽象工厂模式”。

2、里氏代换原则

里氏代换原则是由“Barbara Liskov”提出的。如果调用的是父类的话,那么换成子类也完全可以运行。比如:

光盘 d=new 盗版盘();

d.();

现在要将“盗版软件”类改为“盗版电影”类,没问题,完全可以运行。Java编译程序会检查程序是否符合里氏代换原则。还记得java继承的一个原则吗?子类 overload方法的访问权限不能小于父类对应方法的访问权限。比如“光盘”中的方法“卖”访问权限是“public”,那么“盗版软件”和“盗版电影”中的“卖”方法就不能是packageprivate,编译不能通过。为什么要这样呢?如果“盗版软件”的“卖”方法是private。那么下面这段代码就不能执行了:

光盘 d=new 盗版软件();

d.();

可以说:里氏代换原则是继承复用的一个基础。

3、合成复用原则

就是说要少用继承,多用合成关系来实现。我们可能曾经这样写过程序:有几个类要与数据库打交道,就写了一个数据库操作的类,然后别的跟数据库打交道的类都继承这个。结果后来,我修改了数据库操作类的一个方法,各个类都需要改动。“牵一发而动全身”!面向对象是要把波动限制在尽量小的范围。

Java中,应尽量针对Interface编程,而非实现类。这样,更换子类不会影响调用它方法的代码。要让各个类尽可能少的跟别人联系,扩展性和维护性才能提高。

4、依赖倒转原则

抽象不应该依赖于细节,细节应当依赖于抽象。

要针对接口编程,而不是针对实现编程。

传递参数,或者在组合聚合关系中,尽量引用层次高的类。

主要是在构造对象时可以动态的创建各种具体对象,当然如果一些具体类比较稳定,就不必再弄一个抽象类做它的父类,这样有画蛇添足的感觉

5、接口隔离原则

定制服务的例子,每一个接口应该是一种角色,不多不少,不干不该干的事,该干的事都要干。降低依赖,降低耦合。

6、抽象类

抽象类不会有实例,一般作为父类为子类继承,一般包含这个系的共同属性和方法。

注意:好的继承关系中,只有叶节点是具体类,其他节点应该都是抽象类,也就是说具体类是不被继承的。将尽可能多的共同代码放到抽象类中。

7、迪米特法则

最少知识原则。就是说:一个实体应当尽量少的与其他实体之间发生相互作用,使得系统功能模块相对独立。

三、设计模式的分类

总体来说设计模式分为三大类:

创建型模式,共五种:工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。

结构型模式,共七种:适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。

行为型模式,共十一种:策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。

其实还有两类:并发型模式和线程池模式。

上述各种设计模式将在接下来的一系列文章中为大家一一呈现,敬请关注。