我的设计模式学习感悟（一）

http://35java.com/zhibo/forum.php?mod=viewthread&tid=250&extra=page%3D3

我们在发现问题到解决问题这个过程中，常会发现很多问题是重复出现的，或是某个问题的变体，外在不同，而本质相同，建筑学上如是，软件行业也是，这些问题的本质就是模式。有人说，设计模式并不是初学者能够理解的，当他们的编程经验到了一定程度，便迫切的需要设计模式来完善自己的代码、优雅自己的设计，以及减少重复编码，这句话也是蛮有道理的，以我的亲身经历来说，当刚开始编程时，拿起那本设计模式的书，郁郁寡欢，将该书搁于书架两年后再次捧起，如遇知音。本文以我在以往项目中遇到的三个编码问题来谈谈学习设计模式的必要性。
一、代码量激增、程序可维护性面临挑战
 

让我们来看几段常见但又不够优雅的代码，这些代码 “你”、“我”、“他”或许都曾写过，但是终有一天你也会与我一样，看着有想撞墙的感觉（如果你写了N久这样的代码，还没有这种感觉，八成你是对编程不再感兴趣了，你对其已经麻木）：
 
1.
过多的if…else判断
if (type == 1) {
//调用获取信息方法1
} else if (type == 2) {
//调用获取信息方法2
   …….
} else {
    //调用获取信息方法7
}
这是我在做一个项目中看到的一段代码，那个条件判断非常之长，有7个条件分支，而且其他有些地方也有根据类型来做不同处理的情况。这些代码对于后阶段的维护简直是一场噩梦。
 
2.
多次载入资源（例如配置文件的读取），引起资源损耗
public
static String getProperty(String propKey) throws Exception ...{
Properties prop =
new Properties();
InputStream propConfFile = Util.class.getClassLoader()
.getResourceAsStream("configure.properties");
//载入propConfFile到prop中，从prop中获取propKey的值，并将其返回
}






该段代码是我以前在一个项目中写的一段代码，该段代码用于读取工程配置文件的属性，但该段代码是存在一些问题的，因为在每次获取属性时，它都重新载入资源，造成了资源的过多损耗。
 
3.
过多依赖实现类
 
1）水果接口类—Fruit.java

 

public interface Fruit {

public void grow();

}

 

2）水果的实现类—Apple.java、Strawberry.java
//略
3）测试类—Test.java
public class Test {
public static void main(String[] args) {
Fruit apple = new Apple();

Fruit strawberry = new Strawberry();
}
}
在我们的项目中尚未采用Spring时，类似这样的程序很多，与实现类的过度耦合是这段代码存在的一个主要问题。
 
在我编码的过程中，遇到的问题还有很多。不够优雅的代码、过于僵硬的设计，等等，下面我将通过如上三个例子讨论一下学习设计模式的必要性和我学习设计模式的经历，以及通过改进如上编码来认识学习设计模式给我们的编码带来的好处。

二、借“设计模式”之力冲出代码包围圈

如上的三段代码，都是存在不少问题的，让我们一一讨论，通过在其中应用设计模式，来优化我们的这三段代码，提高其扩展性和易维护性。

1.
解决过多的if…else判断问题

如果在一段代码中，不少地方需根据某类型或状态等做出不同的处理，那当类型或状态增加时，这些代码将会过于僵硬，扩展性差，只有在各个分布了if…else的再增加一个else if，可维护性可想而知。设计模式中有一种模式可以解决该问题，即状态模式。状态模式给我们带来的好处如下：
   1） 状态模式需要对每一个对每一个系统可能取得的状态创立一个状态类（State）的子类，当系统的状态变化时，系统改变所选的子类。与一个特定的状态有关的行为都被包装在一个特定的对象里，而且当需要增加新的状态时，可以以子类的方式将它加到系统里，从而提高了易维护性和可扩展性；
2）由于每一个状态都被包装到了类里面，避免了使用过多的条件转移语句。
下面我们对该例进行演示性的改进。我们可以定义一个类型接口，该类相当于状态模式中的状态类。
public interface Type {
    /**
     * 获取信息
     */
    public Object getInfo();

    /**
     * 获取结果
     */
    public Object getResult();
}
类型1、类型2等可以实现该接口，代码略：


2. 解决过度资源损耗问题

在该例中，每次通过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的回收站在整个系统中只有唯一的一个实例，而且回收站自行提供自己的实例，回收站也是单例模式的应用