从优秀迈向卓越 -- 我的设计模式学习感悟

 http://tech.it168.com/j/2007-05-17/200705170858843_1.shtml

 

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

 

一、代码量激增、程序可维护性面临挑战

 

   让我们来看几段常见但又不够优雅的代码，这些代码 “你”、“我”、“他”或许都曾写过，但是终有一天你也会与我一样，看着有想撞墙的感觉（如果你写了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 的回收站在整个系统中只有唯一的一个实例，而且回收站自行提供自己的实例，回收站也是单例模式的应用

 

3、  解决过多依赖实现类问题

 

在该例的测试类Test.java中，通过Fruit apple = new Apple();来获得对象，造成了程序过多的依赖实现类，与实现类过度耦合，学习设计模式后，我们可以考虑采用工厂模式来实现,可对代码进行如下改进：增加工厂类FruitGardener.java，该类的工厂方法如下：

      
      

       
       
       
       public static Fruit factory(String fruitType) ...
       
       {
if (fruitType.equalsIgnoreCase("apple")) ...{
        return new Apple();
    } else if (fruitType.equalsIgnoreCase("strawberry")) ...{
        return new Strawberry();
    } else ...{
        return null;
    }
}
       
       

      
      

 

增加了水果工厂类后，测试类也要做对应修改，修改后的Test.java的main方法如下：

Fruit apple = FruitGardener.factory("apple");

Fruit strawberry = FruitGardener.factory("strawberry");

 

在进行了对应修改后，测试类大大减少了对水果实现类的依赖，由直接new实现类变成了通过传入字符串来获得需要的实例，工厂模式应用很广泛，例如在现在红得似火的spring也在不少地方用了工厂模式，它本身就是一个很大的bean工厂，不过它在代码上进行了更大的改进，各实现类可以通过配置文件设置。

 

三、设计模式 –––– 由优秀迈向卓越的阶梯

   从以上三个例子中我们可以看出，通过使用设计模式，优化了我们的代码。这样的例子在我们日常的编码过程中有很多，在我们刚开始学习编码时，写这样的代码还说得过去，但随着经验的增长，我们需要更进一步，现有的设计模式给我们提供了解决大多数问题的好方案，当然，在实践的过程中，我们甚至可以探索出新的设计模式，来解决遇到的某类问题。

   学习设计模式不是一蹴而就的，很多人叹息设计模式似乎很不错，然而在自己的编码设计生涯中用得极少，我想主要原因是因为对设计模式的学习还不够，还没将其变成属于自己脑袋里的东西，所以当问题变着面孔出现时，认识不到问题的存在，因为不能正确的分析问题、认识问题，当然也不可能很好的解决问题。

   还未学习过设计模式或对其知之甚少的程序员们，努力学习设计模式吧，那将使你由一个优秀的程序员(Coder)成为一个卓越的软件设计师(Developer)。