本文介绍了设计模式的基本概念及分类，包括创建型、结构型和行为型模式，并通过具体实例展示了如何利用状态模式和单例模式解决编程中常见的问题。
首先了解设计模式的概念，及其基本的分类。
什么是设计模式呢? 一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：
[color=red]创建型设计模式[/color]，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等
[color=red]结构型设计模式[/color]，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等
[color=red]行为型模式[/color]，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。
先通过几个简单例子的说明来介绍在设计模式实际的软件开发中的使用。
让我们来看几段常见但又不够优雅的代码，这些代码 “你”、“我”、“他”或许都曾写过，但是终有一天你也会与我一样，看着有想撞墙的感觉（如果你写了N久这样的代码，还没有这种感觉，八成你是对编程不再感兴趣了，你对其已经麻木）：
[color=red]1.过多的if…else判断[/color]
if (type == 1) {
//调用获取信息方法1
} else if (type == 2) {
//调用获取信息方法2
…….
} else {
//调用获取信息方法7
}
这是我们在编程或者看书中要遇到的一段代码，如果条件判断非常之长，并且其他有些地方也有根据类型来做不同处理的情况。这些代码对于后阶段的维护简直是一场噩梦。
[color=red]2.多次载入资源（例如配置文件的读取），引起资源损耗[/color]
public static String getProperty(String propKey) throws Exception ...{
Properties prop = new Properties();
InputStream propConfFile = Util.class.getClassLoader()
.getResourceAsStream("configure.properties");
//载入propConfFile到prop中，从prop中获取propKey的值，并将其返回
}
该段代码是我以前在一个项目中写的一段代码，该段代码用于读取工程配置文件的属性，但该段代码是存在一些问题的，因为在每次获取属性时，它都重新载入资源，造成了资源的过多损耗。
在我编码的过程中，遇到的问题还有很多。不够优雅的代码、过于僵硬的设计，等等，下面我将通过如上两个例子讨论-----
[color=red]
1. 解决过多的if…else判断问题[/color]
如果在一段代码中，不少地方需根据某类型或状态等做出不同的处理，那当类型或状态增加时，这些代码将会过于僵硬，扩展性差，只有在各个分布了if…else的再增加一个else if，可维护性可想而知。设计模式中有一种模式可以解决该问题，即状态模式。状态模式给我们带来的好处如下：
1） 状态模式需要对每一个对每一个系统可能取得的状态创立一个状态类（State）的子类，当系统的状态变化时，系统改变所选的子类。与一个特定的状态有关的行为都被包装在一个特定的对象里，而且当需要增加新的状态时，可以以子类的方式将它加到系统里，从而提高了易维护性和可扩展性；
2）由于每一个状态都被包装到了类里面，避免了使用过多的条件转移语句。
下面我们对该例进行演示性的改进。我们可以定义一个类型接口，该类相当于状态模式中的状态类。
public interface Type {
public Object getInfo();
public Object getResult();
}
类型1、类型2等可以实现该接口，代码略：
[color=red]
2. 解决过度资源损耗问题[/color]
在该例中，每次通过getProperty(…)方法获取某属性时，都会重新载入文件中的所有内容，造成资源的不必要损耗。该设计模式中，对于此种情况，可以通过单例（Singleton）模式来优化处理。
import //略
public class PropertiesUtil ...{
private static Map propertiesMap = null;
public static String getProperty(String propKey) throws Exception ...{
if (propertiesMap == null) ...{
//当propertiesMap为空时，载入文件，将其键值对放入propertiesMap中(略)
}
//在propertiesMap中获得propKey属性，并将值返回（略）
}
}
可以考虑实现单例模式的地方还有很多，例如：
1）对于计算机的外部资源打印机的情况，因只有一个Printer Spooler，为避免两个打印作业同时输出到打印机中，可考虑用单例模式实现。
2）Window的回收站在整个系统中只有唯一的一个实例，而且回收站自行提供自己的实例，回收站也是单例模式的应用
总结：
在使用了设计模式后，明显的发现以下几点::
1） 可以比较好的分工(比如，使用接口类型模式)
2） 代码组织更有条理(b比如buiilder模式：像查询的结果，中间的产生过程是非常复杂的，如果不用builder模式，谁去改了，也许过段时间，他自己都忘记了)
但是：[color=red]千万不能为了模式而模式。重要的是各种模式中的思想，当你理解了思想之后，在实际的开发中不用想着硬套，自己就会想到使用（就算你已经忘记它是什么模式）。[/color]
原文网址：[url]http://blog.youkuaiyun.com/yinyuan1987/archive/2008/11/03/3209783.aspx[/url]
什么是设计模式呢? 一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。
设计模式常常划分成不同的种类，常见的种类有：
[color=red]创建型设计模式[/color]，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等
[color=red]结构型设计模式[/color]，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等
[color=red]行为型模式[/color]，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。
以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。
先通过几个简单例子的说明来介绍在设计模式实际的软件开发中的使用。
让我们来看几段常见但又不够优雅的代码，这些代码 “你”、“我”、“他”或许都曾写过，但是终有一天你也会与我一样，看着有想撞墙的感觉（如果你写了N久这样的代码，还没有这种感觉，八成你是对编程不再感兴趣了，你对其已经麻木）：
[color=red]1.过多的if…else判断[/color]
if (type == 1) {
//调用获取信息方法1
} else if (type == 2) {
//调用获取信息方法2
…….
} else {
//调用获取信息方法7
}
这是我们在编程或者看书中要遇到的一段代码，如果条件判断非常之长，并且其他有些地方也有根据类型来做不同处理的情况。这些代码对于后阶段的维护简直是一场噩梦。
[color=red]2.多次载入资源（例如配置文件的读取），引起资源损耗[/color]
public static String getProperty(String propKey) throws Exception ...{
Properties prop = new Properties();
InputStream propConfFile = Util.class.getClassLoader()
.getResourceAsStream("configure.properties");
//载入propConfFile到prop中，从prop中获取propKey的值，并将其返回
}
该段代码是我以前在一个项目中写的一段代码，该段代码用于读取工程配置文件的属性，但该段代码是存在一些问题的，因为在每次获取属性时，它都重新载入资源，造成了资源的过多损耗。
在我编码的过程中，遇到的问题还有很多。不够优雅的代码、过于僵硬的设计，等等，下面我将通过如上两个例子讨论-----
[color=red]
1. 解决过多的if…else判断问题[/color]
如果在一段代码中，不少地方需根据某类型或状态等做出不同的处理，那当类型或状态增加时，这些代码将会过于僵硬，扩展性差，只有在各个分布了if…else的再增加一个else if，可维护性可想而知。设计模式中有一种模式可以解决该问题，即状态模式。状态模式给我们带来的好处如下：
1） 状态模式需要对每一个对每一个系统可能取得的状态创立一个状态类（State）的子类，当系统的状态变化时，系统改变所选的子类。与一个特定的状态有关的行为都被包装在一个特定的对象里，而且当需要增加新的状态时，可以以子类的方式将它加到系统里，从而提高了易维护性和可扩展性；
2）由于每一个状态都被包装到了类里面，避免了使用过多的条件转移语句。
下面我们对该例进行演示性的改进。我们可以定义一个类型接口，该类相当于状态模式中的状态类。
public interface Type {
public Object getInfo();
public Object getResult();
}
类型1、类型2等可以实现该接口，代码略：
[color=red]
2. 解决过度资源损耗问题[/color]
在该例中，每次通过getProperty(…)方法获取某属性时，都会重新载入文件中的所有内容，造成资源的不必要损耗。该设计模式中，对于此种情况，可以通过单例（Singleton）模式来优化处理。
import //略
public class PropertiesUtil ...{
private static Map propertiesMap = null;
public static String getProperty(String propKey) throws Exception ...{
if (propertiesMap == null) ...{
//当propertiesMap为空时，载入文件，将其键值对放入propertiesMap中(略)
}
//在propertiesMap中获得propKey属性，并将值返回（略）
}
}
可以考虑实现单例模式的地方还有很多，例如：
1）对于计算机的外部资源打印机的情况，因只有一个Printer Spooler，为避免两个打印作业同时输出到打印机中，可考虑用单例模式实现。
2）Window的回收站在整个系统中只有唯一的一个实例，而且回收站自行提供自己的实例，回收站也是单例模式的应用
总结：
在使用了设计模式后，明显的发现以下几点::
1） 可以比较好的分工(比如，使用接口类型模式)
2） 代码组织更有条理(b比如buiilder模式：像查询的结果，中间的产生过程是非常复杂的，如果不用builder模式，谁去改了，也许过段时间，他自己都忘记了)
但是：[color=red]千万不能为了模式而模式。重要的是各种模式中的思想，当你理解了思想之后，在实际的开发中不用想着硬套，自己就会想到使用（就算你已经忘记它是什么模式）。[/color]
原文网址：[url]http://blog.youkuaiyun.com/yinyuan1987/archive/2008/11/03/3209783.aspx[/url]
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
