1. 程式人生 > >設計模式之狀態模式(三)

設計模式之狀態模式(三)

上次我們很愉快的完成了狀態模式的定義和程式碼的編寫,但是在第一篇的時候我們說過,還需要實現一個抽十次中一次的功能,上次還沒解決呢。

我們已經實現了狀態模式,所以實現這個遊戲應該易如反掌。首先,我們要在GumballMachine類中加入一個狀態:

    State soldOutState;
    State noQuarterState;
    State hasQuarterState;
    State soldState;
    // 這是新加的狀態
    State winnerState;

然後,我們去實現WinnerState類本身,它和SoldState類很像:

public class WinnerState implements State {
    GumballMachine gumballMachine;
 
    public WinnerState(GumballMachine gumballMachine) {
        this.gumballMachine = gumballMachine;
    }
 
    public void insertQuarter() {
        System.out.println("Please wait, we're already giving you a Gumball");
    }
 
    public void ejectQuarter() {
        System.out.println("Please wait, we're already giving you a Gumball");
    }
 
    public void turnCrank() {
        System.out.println("Turning again doesn't get you another gumball!");
    }
 
    // 我們在這裡釋放出兩顆糖果,讓你和進入NoQuarterState或SoldOutState
    public void dispense() {
        gumballMachine.releaseBall();
        if (gumballMachine.getCount() == 0) {
            gumballMachine.setState(gumballMachine.getSoldOutState());
        } else {
            gumballMachine.releaseBall();
            System.out.println("YOU'RE A WINNER! You got two gumballs for your quarter");
            if (gumballMachine.getCount() > 0) {
                gumballMachine.setState(gumballMachine.getNoQuarterState());
            } else {
                System.out.println("Oops, out of gumballs!");
                gumballMachine.setState(gumballMachine.getSoldOutState());
            }
        }
    }
 
    public void refill() { }
    
    public String toString() {
        return "despensing two gumballs for your quarter, because YOU'RE A WINNER!";
    }
}

完成這個遊戲

我們還要做一個改變:我們需要實現機會隨機數,還要增加一個進入WinnerState狀態的轉換。這兩件事都要加進HasQuarterState,因為顧客會從這個狀態轉動曲柄:

public class HasQuarterState implements State {
    // 首先,我們增加一個隨機數產生器,產生10%贏的機會
    Random randomWinner = new Random(System.currentTimeMillis());
    GumballMachine gumballMachine;
 
    public HasQuarterState(GumballMachine gumballMachine) {
        this.gumballMachine = gumballMachine;
    }
  
    public void insertQuarter() {
        System.out.println("You can't insert another quarter");
    }
 
    public void ejectQuarter() {
        System.out.println("Quarter returned");
        gumballMachine.setState(gumballMachine.getNoQuarterState());
    }
 
    // 然後決定這個顧客是否贏了
    public void turnCrank() {
        System.out.println("You turned...");
        int winner = randomWinner.nextInt(10);
        if ((winner == 0) && (gumballMachine.getCount() > 1)) {
            gumballMachine.setState(gumballMachine.getWinnerState());
        } else {
            gumballMachine.setState(gumballMachine.getSoldState());
        }
    }

    public void dispense() {
        System.out.println("No gumball dispensed");
    }
    
}

剩下的就是如何向客戶展示的問題了,還是老樣子,給出程式碼,執行自己去執行哦。我們貴在實踐嘛。

public class GumballMachineTestDrive {

    public static void main(String[] args) {
        GumballMachine gumballMachine = 
            new GumballMachine(10);

        System.out.println(gumballMachine);

        gumballMachine.insertQuarter();
        gumballMachine.turnCrank();
        gumballMachine.insertQuarter();
        gumballMachine.turnCrank();

        System.out.println(gumballMachine);
        // 多重複幾次,就可以看是否中獎了
    }
}

到這裡為止,我們通過狀態模式把這個知識點鞏固了,只是如果這些程式碼提交出去,還是有很多待改進的地方,主要是GumballMachine這個類,在這裡就不一一贅述啦,感興趣的朋友可以自己先看看程式碼,或者檢視下書籍,書籍裡有你想要的答案哦。可能很多朋友剛開始看,我們參考的書籍是《Head First設計模式》,公眾號內回覆設計模式即可獲取電子書查閱。

設計箱內的工具

萬年不變的總結時間來啦

  • OO基礎

    抽象、封裝、繼承、多型

  • OO原則(本章沒有新的設計原則出現哦)

    封裝變化

    多用組合,少用繼承

    針對介面程式設計,不針對實現程式設計

    為互動物件之間的鬆耦合設計而努力

    依賴抽象,不要依賴具體類

    類應該對擴充套件開放,對修改關閉

    只和朋友交談

    別找我,我會找你

    類應該只有一個改變的理由

  • OO模式

    『策略模式』、『觀察者模式』、『裝飾者模式』、『抽象工廠模式』、『工廠方法模式』、『單例模式』、『命令模式』、『介面卡模式』、『外觀模式』、『模板方法模式』、『迭代器模式』、『組合模式』

    『狀態模式』允許物件在內部狀態改變時改變它的行為,物件看起來好像修改了它的類。

第10章的內容學完了。小編最近在看後面的章節,篇幅有點長,有部分內容和我們現在的使用方式存在不同,所以小編現在也在苦惱如何將後面的章節通過精簡的方式整理出來。

小編試著努力下看看,如果可以,小編竭盡所能給大家貢獻出來。倘若有難度了,小編會找網上優秀的部落格來補充這一部分的內容,把後續的補充完。感謝大家一如既往地支援與厚愛,謝謝。

相關推薦

設計模式狀態模式

上次我們很愉快的完成了狀態模式的定義和程式碼的編寫,但是在第一篇的時候我們說過,還需要實現一個抽十次中一次的功能,上次還沒解決呢。 我們已經實現了狀態模式,所以實現這個遊戲應該易如反掌。首先,我們要在GumballMachine類中加入一個狀態: State soldOutState; Sta

設計模式- 狀態模式State Pattern

mage player out read end des 我們 能夠 esp 狀態模式 在狀態模式(State Pattern)中,類的行為是基於它的狀態改變的。這種類型的設計模式屬於行為型模式。 在狀態模式中,我們創建表示各種狀態的對象和一個行為隨著狀態對象改變而改變的

設計模式狀態模式State Pattern

簡介: 在狀態模式(State Pattern)中,類的行為是基於它的狀態改變的。這種型別的設計模式屬於行為型模式。 在狀態模式中,我們建立表示各種狀態的物件和一個行為隨著狀態物件改變而改變的 context 物件。 意圖:允許物件在內部狀態發生改變時改變它的行為,物件看起來好像修改了它的類

設計模式問題集錦

是把 後繼 ogr data- 跟著 沒有 解釋器 space 基本實現 設計模式的主要資料是《大話設計模式》。第一階段先看看各種模式的基本概念。實現每一個模式下的樣例。然後在進行理解性的學習和掌握,靈活掌握各種模式的長處,知道某種模式適合那種狀態。如今,樣

《大話設計模式》——讀後感 8好菜每回味不同——建造者模式基礎案例1

ted builds src ret 分離 args 類圖 rec 方法 建造者模式:是將一個復雜的對象的構建與它的表示分離,使得同樣的構建過程可以創建不同的表示。 建造者模式通常包括下面幾個角色: 1. builder:給出一個抽象接口,以規範產品對象的各個組成成分的

設計模式六大原則轉載

具體類 ima 傳遞參數 基礎上 比較 擁有 tex 至少 基類 關於設計模式的六大設計原則的資料網上很多,但是很多地方解釋地都太過於籠統化,我也找了很多資料來看,發現CSDN上有幾篇關於設計模式的六大原則講述的比較通俗易懂,因此轉載過來。   原作者博客鏈接:http:/

設計模式簡單小例子行為型模式

終於,把設計模式小例子敲完了..... 原始碼已經上傳到了GitHub. https://github.com/tanglonghui/DesignPatterns 設計模式簡單小例子(一) 建立型模式: https://blog.csdn.net/qq_40687864/artic

Java設計模式總體簡介——簡單易懂

設計模式(Design pattern)是一套被反覆使用、多數人知曉的、經過分類編目的、程式碼設計經驗的總結。使用設計模式是為了可重用程式碼、讓程式碼更容易被他人理解、保證程式碼可靠性。 毫無疑問,設計模式於己於他人於系統都是多贏的,設計模式使程式碼編制真正工程化,設計模式是

設計模式——java版》

三、抽象工廠模式         1.為建立一組相關或相互依賴的物件提供一個介面,而且無須指定它們的具體類。抽象工廠模式是工廠方法模式的升級版本。在有多個業務品種、業務分類時,通過抽象工廠模式產生需要的物件是一種非常好的解決方式。   &

學習路-RabbitMQ:RabbitMQ的工作模式

RabbitMQ有以下幾種工作模式 : 1、Work queues 工作佇列 2、Publish/Subscribe 釋出訂閱模式 3、Routing 路由模式 4、Topics 萬用字元模式 5、Header 6、RPC 一:Work queues 工作佇列 work queues與

設計模式裝飾者Decorator模式

首先來看一個場景,如圖: 工人分為很多種類,比如電工,管道工等等,同時又有A公司的電工,B公司的電工,A公司的管道工,B公司的管道工等等,那麼當有M個工種和N個公司的時候,就會有 M * N 個子類,這個繼承體系就會變得很龐大和複雜。那麼如何簡化呢,那麼

Javascript設計模式簡單工廠

建立型設計模式-簡單工廠模式 簡單工廠模式(Simple Factory):又稱之為靜態工廠模式,由一個工廠物件建立某一種產品物件類的例項。主要用來建立同一類物件。 多類單例項法 為了加深我們的理解,設定以下需求。假設一個大型超市賣各種東西,

設計模式美學習:為何說要多用組合少用繼承?如何決定該用組合還是繼承?

在面向物件程式設計中,有一條非常經典的設計原則,那就是:組合優於繼承,多用組合少用繼承。為什麼不推薦使用繼承?組合相比繼承有哪些優勢?如何判斷該用組合還是繼承? 為什麼不推薦使用繼承? 繼承是面向物件的四大特性之一,用來表示類之間的 is-a 關係,可以解決程式碼複用的問題。雖然繼承有諸多作用,但繼承層次過深

設計模式美學習:業務開發常用的基於貧血模型的MVC架構違背OOP嗎?

我們都知道,很多業務系統都是基於 MVC 三層架構來開發的。實際上,更確切點講,這是一種基於貧血模型的 MVC 三層架構開發模式。 雖然這種開發模式已經成為標準的 Web 專案的開發模式,但它卻違反了面向物件程式設計風格,是一種徹徹底底的面向過程的程式設計風格,因此而被有些人稱為反模式(anti-patter

設計模式狀態模式

分支語句 控制 查看 cti get 裏的 抽象類 href 其它 設計模式之狀態模式 May 22, 2015 狀態模式(State)允許一個對象在其內部狀態改變的時候改變它的行為,對象看起來似乎修改了它的類。 正文 舉個例子,就比如我們平時在下載東西,通常就會有好幾個

設計模式狀態模式(State)摘錄

表示 facade test true efi 子類 ble 叠代 系列 23種GOF設計模式一般分為三大類:創建型模式、結構型模式、行為模式。創建型模式抽象了實例化過程,它們幫助一個系統獨立於怎樣創建、組合和表示它的那些對象。一個類創建型模式使用繼承改變被實例化的類,而

C++設計模式狀態模式(二)

virtual alt 虛構函數 需求 rate names clas term delete 2、智能空調的設計與實現 某軟件公司將開發一套智能空調系統: 系統檢測到溫度處於20---30度之間,則切換到常溫狀態;溫度處於30---45度,則切換到制冷狀態;

Head First設計模式狀態模式

對象狀態 initial fff rst actions arc sof ret %20 一、定義 定義:允許對象在內部狀態改變時改變它的行為, 對象看起來好像修改了它的類。 主要解決:對象的行為依賴於它的狀態(屬性),並且可以根據它的狀態改變而改變它的相關行為。 何

C++設計模式狀態模式

程序 class lse 轉移 tchar pri dot ace RKE 當一個對象的內在狀態改變時允許改變其行為,這個對象看起來像是改變了其類。 狀態模式主要解決的是當控制一個對象狀態轉換的條件表達式過於復雜時的情況。把狀態的判斷邏輯轉移到表示不同狀態的

哈爾濱工業大學計算機學院-模式識別-課程總結-線性判別函數

的區別 技術 方便 img 上進 lms amp 計算 生成 1. 線性判別函數 本章介紹的線性判別函數都歸屬於判別式模型,即對於分類問題,根據判別函數\(g(x)\)的取值進行判斷,比如正數歸為第一類,負數與零歸為第二類。關於判別式模版與生成式模型的區別可以閱讀我以前的