設計模式； 一個程序員對設計模式的理解: “不懂”為什么要把很簡單的東西搞得那么復雜。后來隨著軟件開發經驗的增加才開始明白我所看到的“復雜”恰恰就是設計模式的精髓所在，我所理解的“簡單”就是一把鑰匙開一把鎖的模式，目的僅僅是著眼于解決現在的問題，而設計模式的“復雜”就在于它是要構造一個“萬能鑰匙”，目的是提出一種對所有鎖的開鎖方案。在真正理解設計模式之前我一直在編寫“簡單”的代碼. 這個“簡單”不是功能的簡單，而是設計的簡單。簡單的設計意味著缺少靈活性，代碼很鋼硬，只在這個項目里有用，拿到其它的項目中就是垃圾，我將其稱之為“一次性代碼”。 -->要使代碼可被反復使用,請用'設計模式'對你的代碼進行設計. 很多我所認識的程序員在接觸到設計模式之后，都有一種相見恨晚的感覺，有人形容學習了設計模式之后感覺自己好像已經脫胎換骨，達到了新的境界，還有人甚至把是否了解設計模式作為程序員劃分水平的標準。 我們也不能陷入模式的陷阱，為了使用模式而去套模式，那樣會陷入形式主義。我們在使用模式的時候，一定要注意模式的意圖（intent），而不要過多的去關注模式的實現細節，因為這些實現細節在特定情況下，可能會發生一些改變。不要頑固地認為設計模式一書中的類圖或實現代碼就代表了模式本身。 設計原則：(重要) 1. 邏輯代碼獨立到單獨的方法中，注重封裝性--易讀，易復用。 不要在一個方法中，寫下上百行的邏輯代碼。把各小邏輯代碼獨立出來，寫于其它方法中，易讀其可重復調用。 2. 寫類，寫方法，寫功能時，應考慮其移植性，復用性：防止一次性代碼！ 是否可以拿到其它同類事物中應該？是否可以拿到其它系統中應該？ 3. 熟練運用繼承的思想： 找出應用中相同之處，且不容易發生變化的東西，把它們抽取到抽象類中，讓子類去繼承它們； 繼承的思想，也方便將自己的邏輯建立于別人的成果之上。如ImageField extends JTextField； 熟練運用接口的思想： 找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。 把很簡單的東西搞得那么復雜，一次性代碼，設計模式優勢的實例說明：（策略模式） 說明： 模擬鴨子游戲的應用程序，要求：游戲中會出現各種顏色外形的鴨子，一邊游泳戲水，一邊呱呱叫。 第一種方法：（一次性代碼） 直接編寫出各種鴨子的類：MallardDuck//野鴨，RedheadDuck//紅頭鴨，各類有三個方法： quack()：叫的方法 swim()：游水的方法 display()：外形的方法 第二種方法：運用繼承的特性，將其中共同的部分提升出來，避免重復編程。 即：設計一個鴨子的超類（Superclass）,并讓各種鴨子繼承這個超類。 public abstract class Duck{public void quack(){ //呱呱叫System.out.println("呱呱叫");}public void swim(){ //游泳System.out.println(" 游泳");} public abstract 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 abstract 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設計了。這樣很顯然的耦合了一起。利用繼承-->耦合度太高了. 第三種方法： 用接口改進. 我們把容易引起變化的部分提取出來并封裝之，來應付以后的變法。雖然代碼量加大了，但可用性提高了，耦合度也降低了。 我們把Duck中的fly方法和quack提取出來。 public interface Flyable{public void fly(); }public interface Quackable{public void quack();}

?最后Duck的設計成為：

public abstract 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接口不具有實現代碼，所以實現接口無法達到代碼的復用。 第四種方法： 對上面各方式的總結: 繼承的好處:讓共同部分,可以復用.避免重復編程. 繼承的不好:耦合性高.一旦超類添加一個新方法,子類都繼承,擁有此方法, ??????????????????????? 若子類相當部分不實現此方法,則要進行大批量修改. ???????????????????????? 繼承時,子類就不可繼承其它類了. 接口的好處:解決了繼承耦合性高的問題. ???????????????????????? 且可讓實現類,繼承或實現其它類或接口. 接口的不好:不能真正實現代碼的復用.可用以下的策略模式來解決. ------------------------- strategy(策略模式) ------------------------- 我們有一個設計原則： 找出應用中相同之處，且不容易發生變化的東西，把它們抽取到抽象類中，讓子類去繼承它們； 找出應用中可能需要變化之處，把它們獨立出來，不要和那些不需要變化的代碼混在一起。 -->important. 現在，為了要分開“變化和不變化的部分”，我們準備建立兩組類（完全遠離Duck類），一個是"fly"相關的，另一個 是“quack”相關的，每一組類將實現各自的動作。比方說，我們可能有一個類實現“呱呱叫”，另一個類實現“吱吱 叫”，還有一個類實現“安靜”。 首先寫兩個接口。FlyBehavior(飛行行為)和QuackBehavior（叫的行為）. public interface FlyBehavior{public void fly(); }public interface QuackBehavior{public void quack();}

我們在定義一些針對FlyBehavior的具體實現。

public class FlyWithWings implements FlyBehavior{public void fly(){//實現了所有有翅膀的鴨子飛行行為。 }}public class FlyNoWay implements FlyBehavior{public void fly(){//什么都不做，不會飛 }}

針對QuackBehavior的幾種具體實現。

public class Quack implements QuackBehavior{public void quack(){//實現呱呱叫的鴨子 } }public class Squeak implements QuackBehavior{public void quack(){//實現吱吱叫的鴨子 } }public class MuteQuack implements QuackBehavior{public void quack(){//什么都不做，不會叫 } }

點評一: 這樣的設計，可以讓飛行和呱呱叫的動作被其他的對象復用，因為這些行為已經與鴨子類無關了。而我們增加一些新

的行為，不會影響到既有的行為類，也不會影響“使用”到飛行行為的鴨子類。 最后我們看看Duck 如何設計。 public abstract class Duck{ --------->在抽象類中,聲明各接口,定義各接口對應的方法.FlyBehavior flyBehavior;//接口QuackBehavior quackBehavior;//接口public Duck(){}public abstract void display();public void swim(){//實現游泳的行為 }public void performFly(){flyBehavior.fly(); //-->由于是接口,會根據繼承類實現的方式,而調用相應的方法.}public void performQuack(){quackBehavior.quack();
　　　　}}

看看MallardDuck如何實現。
----->通過構造方法,生成'飛','叫'具體實現類的實例,從而指定'飛','叫'的具體屬性

public class MallardDuck extends Duck{public MallardDuck { flyBehavior = new FlyWithWings ();quackBehavior = new Quack(); //因為MallardDuck 繼承了Duck，所有具有flyBehavior 與quackBehavior 實例變量}public void display(){//實現 }}

?這樣就滿足了即可以飛，又可以叫，同時展現自己的顏色了。

這樣的設計我們可以看到是把flyBehavior ，quackBehavior 的實例化寫在子類了。我們還可以動態的來決定。 ? 我們只需在Duck中加上兩個方法。 在構造方法中對屬性進行賦值與用屬性的setter的區別： 構造方法中對屬性進行賦值：固定，不可變； 用屬性的setter，可以在實例化對象后，動態的變化，比較靈活。 public abstract class Duck{FlyBehavior flyBehavior;//接口QuackBehavior quackBehavior;//接口public void setFlyBehavior(FlyBehavior flyBehavior){this.flyBehavior = flyBehavior;}public void setQuackBehavior(QuackBehavior quackBehavior {this.quackBehavior= quackBehavior;}}

本文出自 “Changes we need ! ” 博客，請務必保留此出處http://shenzhenchufa.blog.51cto.com/730213/161581

?

轉載于:https://www.cnblogs.com/orangesea/p/4075414.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的Java的设计模式----strategy(策略模式)的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。