设计模式;

  一个程序员对设计模式的理解:

  “不懂”为什么要把很简单的东西搞得那么复杂。后来随着软件开发经验的增加才开始明白我所看到的“复杂”恰恰是设计模式的精髓所在,我所理解的“简单”是一把钥匙开一把锁的模式,目的仅仅是着眼于解决现在的问题,而设计模式的“复杂”在于它是要构造一个“钥匙”,目的是提出一种对所有锁的开锁方案。在真正理解设计模式之前我一直在编写“简单”的代码.

  这个“简单”不是功能的简单,而是设计的简单。简单的设计意味着缺少灵活性,代码很钢硬,只在这个项目里有用,拿到其它的项目中是垃圾,我将其称之为“一次性代码”。

  -->要使代码可被反复使用,请用'设计模式'对你的代码进行设计.

  很多我所认识的程序员在接触到设计模式之后,都有一种相见恨晚的感觉,有人形容学习了设计模式之后感觉自己好像已经脱胎换骨,达到了新的境界,还有人甚至把是否了解设计模式作为程序员划分水平的标准。

  我们也不能陷入模式的陷阱,为了使用模式而去套模式,那样会陷入形式主义。我们在使用模式的时候,一定要注意模式的意图(intent),而不 要过多的去关注模式的实现细节,因为这些实现细节在特定情况下,可能会发生一些改变。不要顽固地认为设计模式一书中的类图或实现代码代表了模式本身。

  设计原则:(重要)

  1.逻辑代码独立到单独的方法中,注重封装性--易读,易复用。

  不要在一个方法中,写下上百行的逻辑代码。把各小逻辑代码独立出来,写于其它方法中,易读其可重复调用。

  2.写类,写方法,写功能时,应考虑其移植性,复用性:防止一次性代码!

  是否可以拿到其它同类事物中应该?是否可以拿到其它系统中应该?

  3.熟练运用继承的思想:

  找出应用中相同之处,且不容易发生变化的东西,把它们抽取到抽象类中,让子类去继承它们;

  继承的思想,也方便将自己的逻辑建立于别人的成果之上。如ImageField extends JTextField;

  熟练运用接口的思想:

  找出应用中可能需要变化之处,把它们独立出来,不要和那些不需要变化的代码混在一起。

  把很简单的东西搞得那么复杂,一次性代码,设计模式优势的实例说明:(策略模式)

  说明:

  模拟鸭子游戏的应用程序,要求:游戏中会出现各种颜色外形的鸭子,一边游泳戏水,一边呱呱叫。

  第一种方法:(一次性代码)

  直接编写出各种鸭子的类:MallardDuck//野鸭,RedheadDuck//红头鸭,各类有三个方法:

  quack():叫的方法

  swim():游水的方法

  display():外形的方法

  第二种方法:运用继承的特性,将其中共同的部分提升出来,避免重复编程。

  即:设计一个鸭子的超类(Superclass),并让各种鸭子继承这个超类。

public class Duck{
public void quack(){  //呱呱叫
System.out.println("呱呱叫");
}
public void swim(){   //游泳
System.out.println(" 游泳");
}
public  abstratact void display(); /*因为外观不一样,让子类自己去决定了。*/
}

  对于它的子类只需简单的继承可以了,并实现自己的display()方法。

//野鸭
public class MallardDuck extends Duck{
public void display(){
System.out.println("野鸭的颜色...");
}
}
//红头鸭
public class RedheadDuck extends Duck{
public void display(){
System.out.println("红头鸭的颜色...");
}
}

  不幸的是,现在客户又提出了新的需求,想让鸭子飞起来。这个对于我们OO程序员,在简单不过了,在超类中在加一个方法可以了。

public class Duck{
public void quack(){  //呱呱叫
System.out.println("呱呱叫");
}
public void swim(){   //游泳
System.out.println(" 游泳");
}
public  abstract void display(); /*因为外观不一样,让子类自己去决定了。*/
public void fly(){
System.out.println("飞吧!鸭子");
}
}

  对于不能飞的鸭子,在子类中只需简单的覆盖。

//残废鸭
public class DisabledDuck extends Duck{
public void display(){
System.out.println("残废鸭的颜色...");
}
public void fly(){
//覆盖,变成什么事都不做。
}
}

  其它会飞的鸭子不用覆盖。

  这样所有的继承这个超类的鸭子都会fly了。但是问题又出来了,客户又提出有的鸭子会飞,有的不能飞。

  >>>>>>点评:

  对于上面的设计,你可能发现一些弊端,如果超类有新的特性,子类都必须变动,这是我们开发不喜欢看到的,一个类变让另一个类也跟着变,这有点不符合OO设计了。这样很显然的耦合了一起。利用继承-->耦合度太高了.