Java的23種設計模式概述
一個程序員對設計模式的理解:
作爲開發人員需要儘可能掌握和熟悉各種設計模式，便於在遇見不同解決方案時，靈活應用達到事半功倍好效果，思路清晰 節約時間 。
“不懂”爲什麼要把很簡單的東西搞得那麼複雜。後來隨着軟件開發經驗的增加纔開始明白我所看到的“複雜”恰恰就是設計模式的精髓所在，我所理解的“簡單”就是一把鑰匙開一把鎖的模式，目的僅僅是着眼於解決現在的問題，而設計模式的“複雜”就在於它是要構造一個“公共鑰匙”，目的是提出一種對所有鎖的開鎖方案。在真正理解設計模式之前我一直在編寫“簡單”的代碼.
這個“簡單”不是功能的簡單，而是設計的簡單。簡單的設計意味着缺少靈活性，代碼很鋼硬，只在這個項目裏有用，拿到其它的項目中就是垃圾，我將其稱之爲“一次性代碼”。
-->要使代碼可被反覆使用,請用'設計模式'對你的代碼進行設計.
很多我所認識的程序員在接觸到設計模式之後，都有一種相見恨晚的感覺，有人形容學習了設計模式之後感覺自己好像已經脫胎換骨，達到了新的境界，還有人甚至把是否瞭解設計模式作爲程序員劃分水平的標準。
我們也不能陷入模式的陷阱，爲了使用模式而去套模式，那樣會陷入形式主義。我們在使用模式的時候，一定要注意模式的意圖（intent），而不要過多的去關注模式的實現細節，因爲這些實現細節在特定情況下，可能會發生一些改變。不要頑固地認爲設計模式一書中的類圖或實現代碼就代表了模式本身。
設計原則：(重要)
1.
邏輯代碼獨立到單獨的方法中，注重封裝性--易讀，易複用。
不要在一個方法中，寫下上百行的邏輯代碼。把各小邏輯代碼獨立出來，寫於其它方法中，易讀其可重複調用。
2.
寫類，寫方法，寫功能時，應考慮其移植性，複用性：防止一次性代碼！
是否可以拿到其它同類事物中應該？是否可以拿到其它系統中應該？
3.
熟練運用繼承的思想：
找出應用中相同之處，且不容易發生變化的東西，把它們抽取到抽象類中，讓子類去繼承它們；
繼承的思想，也方便將自己的邏輯建立於別人的成果之上。如ImageField extends JTextField；
熟練運用接口的思想：
找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。
把很簡單的東西搞得那麼複雜，一次性代碼，設計模式優勢的實例說明：（策略模式）
說明：
模擬鴨子游戲的應用程序，要求：遊戲中會出現各種顏色外形的鴨子，一邊游泳戲水，一邊呱呱叫。
第一種方法：運用繼承的特性，將其中共同的部分提升出來，避免重複編程。
即：設計一個鴨子的超類（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設計了。這樣很顯然的耦合了一起。利用繼承-->耦合度太高了.
第二種方法：（一次性代碼）
直接編寫出各種鴨子的類：MallardDuck//野鴨，RedheadDuck//紅頭鴨，各類有三個方法：
quack()：叫的方法
swim()：游水的方法
display()：外形的方法
第三種方法：
用接口改進.
我們把容易引起變化的部分提取出來並封裝之，來應付以後的變法。雖然代碼量加大了，但可用性提高了，耦合度也降低了。
我們把Duck中的fly方法和quack提取出來。
public interface Flyable{
public void fly();
}
public interface Quackable{
public void quack();
}
最後Duck的設計成爲：
public class Duck{
public void swim(){ //游泳
System.out.println(" 游泳");
}
public abstract void display();
}
而MallardDuck,RedheadDuck,DisabledDuck 就可以寫成爲：
//野鴨
public class MallardDuck extends Duck implements Flyable,Quackable{
public void display(){
System.out.println("野鴨的顏色...");
}
public void fly(){
//實現該方法
}
public void quack(){
//實現該方法
}
}
//紅頭鴨
public class RedheadDuck extends Duck implements Flyable,Quackable{
public void display(){
System.out.println("紅頭鴨的顏色...");
}
public void fly(){
//實現該方法
}
public void quack(){
//實現該方法
}
}
//殘廢鴨 只實現Quackable（能叫不能飛）
public class DisabledDuck extends Duck implements Quackable{
public void display(){
System.out.println("殘廢鴨的顏色...");
}
public void quack(){
//實現該方法
}
}
>>>>>>點評:
好處:
這樣已設計，我們的程序就降低了它們之間的耦合。
不足:
Flyable和 Quackable接口一開始似乎還挺不錯的，解決了問題（只有會飛到鴨子才實現 Flyable），但是Java接口不具有實現代碼，所以實現接口無法達到代碼的複用。
第四種方法：
對上面各方式的總結:
繼承的好處:讓共同部分,可以複用.避免重複編程.
繼承的不好:耦合性高.一旦超類添加一個新方法,子類都繼承,擁有此方法,
若子類相當部分不實現此方法,則要進行大批量修改.
繼承時,子類就不可繼承其它類了.
接口的好處:解決了繼承耦合性高的問題.
且可讓實現類,繼承或實現其它類或接口.
接口的不好:不能真正實現代碼的複用.可用以下的策略模式來解決.
其他設計模式:
java 23種設計模式之 一 狀態模式(state)
java 23種設計模式之 一 代理模式(Proxy)
java 23種設計模式之 一 適配器模式(adapter)
java 23種設計模式之 一 外觀模式(Facade)
java 23種設計模式之 一 迭代器模式(Iterator)
java 23種設計模式之 一 觀察者模式(Observer)
java 23種設計模式之 一 單例模式 (singelton)
java 23種設計模式之 一 靜態工廠 ( static Factory Method )
java 23種設計模式之 一 策略模式（strategy）
更多Java中23中設計模式中文文檔下載