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

该段代码是我以前在一个项目中写的一段代码，该段代码用于读取工程配置文件的属性， 但该段代码是存在一些问题的，因为在每次获取属性时，它都重新载入资源，造成了资源的过多 损耗。
3. 过多依赖实现类
1）水果接口类—Fruit.java
public interface Fruit { public void grow();
容，造成资源的不必要损耗。该设计模式中，对于此种情况，可以通过单例（Singleton）模式 来优化处理。
import //略 public class PropertiesUtil { private static Map propertiesMap = null; public static String getProperty(String propKey) throws Exception
}
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();
从优秀迈向卓越 -- 我的设计模式学习感悟
我们在发现问题到解决问题这个过程中，常会发现很多问题是重复出现的，或是某个问题 的变体，外在不同，而本质相同，建筑学上如是，软件行业也是，这些问题的本质就是模式。有 人说，设计模式并不是初学者能够理解的，当他们的编程经验到了一定程度，便迫切的需要设计 模式来完善自己的代码、优雅自己的设计，以及减少重复编码，这句话也是蛮有道理的，以我的 亲身经历来说，当刚开始编程时，拿起那本设计模式的书，郁郁寡欢，将该书搁于书架两年后再 次捧起，如遇知音。本文以我在以往项目中遇到的三个编码问题来谈谈学习设计模式的必要性。
1）
对于计算机的外部资源打印机的情况，因只有一个 Printer Spooler，为避免两个打印作业同
时输出到打印机中，可考虑用单例模式实现。
2）
Window 的回收站在整个系统中只有唯一的一个实例，而且回收站自行提供自己的实例，回收
站也是单例模式的应用
3、 解决过多依 中，通过 Fruit apple = new Apple();来获得对象，造成了程序 过多的依赖实现类，与实现类过度耦合，学习设计模式后，我们可以考虑采用工厂模式来实现, 可对代码进行如下改进：增加工厂类 FruitGardener.java，该类的工厂方法如下：
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 的值，并将其返回 }
二、借“设计模式”之力冲出代码包围圈
如上的三段代码，都是存在不少问题的，让我们一一讨论，通过在其中应用设计模式，来 优化我们的这三段代码，提高其扩展性和易维护性。
1. 解决过多的 if…else 判断问题 如果在一段代码中，不少地方需根据某类型或状态等做出不同的处理，那当类型或状态增
加时，这些代码将会过于僵硬，扩展性差，只有在各个分布了 if…else 的再增加一个 else if， 可维护性可想而知。设计模式中有一种模式可以解决该问题，即状态模式。状态模式给我们带来 的好处如下：
在进行了对应修改后，测试类大大减少了对水果实现类的依赖，由直接 new 实现类变成了通 过传入字符串来获得需要的实例，工厂模式应用很广泛，例如在现在红得似火的 spring 也在不 少地方用了工厂模式，它本身就是一个很大的 bean 工厂，不过它在代码上进行了更大的改进， 各实现类可以通过配置文件设置。
return new Strawberry(); } else {
return null; } }
增加了水果工厂类后，测试类也要做对应修改，修改后的 Test.java 的 main 方法如下： Fruit apple = FruitGardener.factory("apple"); Fruit strawberry = FruitGardener.factory("strawberry");
public static Fruit factory(String fruitType) { if (fruitType.equalsIgnoreCase("apple")) {
return new Apple(); } else if (fruitType.equalsIgnoreCase("strawberry")) {
} }
在我们的项目中尚未采用 Spring 时，类似这样的程序很多，与实现类的过度耦合是这段代 码存在的一个主要问题。
在我编码的过程中，遇到的问题还有很多。不够优雅的代码、过于僵硬的设计，等等，下面 我将通过如上三个例子讨论一下学习设计模式的必要性和我学习设计模式的经历，以及通过改进 如上编码来认识学习设计模式给我们的编码带来的好处。
三、设计模式 –––– 由优秀迈向卓越的阶梯 从以上三个例子中我们可以看出，通过使用设计模式，优化了我们的代码。这样的例子在
我们日常的编码过程中有很多，在我们刚开始学习编码时，写这样的代码还说得过去，但随着经 验的增长，我们需要更进一步，现有的设计模式给我们提供了解决大多数问题的好方案，当然， 在实践的过程中，我们甚至可以探索出新的设计模式，来解决遇到的某类问题。
学习设计模式不是一蹴而就的，很多人叹息设计模式似乎很不错，然而在自己的编码设计 生涯中用得极少，我想主要原因是因为对设计模式的学习还不够，还没将其变成属于自己脑袋里 的东西，所以当问题变着面孔出现时，认识不到问题的存在，因为不能正确的分析问题、认识问 题，当然也不可能很好的解决问题。
还未学习过设计模式或对其知之甚少的程序员们，努力学习设计模式吧，那将使你由一个 优秀的程序员(Coder)成为一个卓越的软件设计师(Developer)。
{ if (propertiesMap == null) { //当 propertiesMap 为空时，载入文件，将其键值对放入
propertiesMap 中(略) } //在 propertiesMap 中获得 propKey 属性，并将值返回（略）
} }
可以考虑实现单例模式的地方还有很多，例如：
1） 状态模式需要对每一个对每一个系统可能取得的状态创立一个状态类（State）的子类， 当系统的状态变化时，系统改变所选的子类。与一个特定的状态有关的行为都被包装在一个特定 的对象里，而且当需要增加新的状态时，可以以子类的方式将它加到系统里，从而提高了易维护 性和可扩展性；
2）由于每一个状态都被包装到了类里面，避免了使用过多的条件转移语句。 下面我们对该例进行演示性的改进。我们可以定义一个类型接口，该类相当于状态模式中的 状态类。 public interface Type {
/** * 获取信息 */
public Object getInfo();
/** * 获取结果 */
public Object getResult(); } 类型 1、类型 2 等可以实现该接口，代码略：
2. 解决过度资源损耗问题 在该例中，每次通过 getProperty(…)方法获取某属性时，都会重新载入文件中的所有内
一、代码量激增、程序可维护性面临挑战
让我们来看几段常见但又不够优雅的代码，这些代码 “你”、“我”、“他”或许都曾写 过，但是终有一天你也会与我一样，看着有想撞墙的感觉（如果你写了 N 久这样的代码，还没有 这种感觉，八成你是对编程不再感兴趣了，你对其已经麻木）：
1. 过多的 if…else 判断 if (type == 1) { //调用获取信息方法 1 } else if (type == 2) { //调用获取信息方法 2 ……. } else { //调用获取信息方法 7 } 这是我在做一个项目中看到的一段代码，那个条件判断非常之长，有 7 个条件分支，而且其 他有些地方也有根据类型来做不同处理的情况。这些代码对于后阶段的维护简直是一场噩梦。