設計模式什麼的哪有那麼神祕 ----第三集 建立延後

上一集咱們聊了設計模式中對於函數參數傳值使用的一些有意思的地方.那麼今天,咱們來聊一聊設計模式中對於函數返回值有哪些有意思的運用.

設計模式中,有一個很常見的思想,就是"讓建立操做延後".

表明模式首先就是工廠系列三大模式.這裏只討論簡單工廠模式.

爲何要讓建立操做延後?

設計模式對於編程最大的貢獻,或者說它宣揚的是讓程序架構靈活,擁抱變化.

假設我如今須要操做A對象

通常狀況下

A a = new A(); 或  Ia a = new A();//Ia表明A類的接口或抽象,推薦用接口的方式聲明.

當咱們寫完功能之後,發現功能並非很好.咱們從新寫一個A2的類,處理方式比A類要好用.

而後咱們須要把程序代碼中全部對A的操做改爲A2.這是多麼大的工做量啊.若是沒有IDE幫助,根本不可能完成.

要知道,加班都是自找的.

咱們能夠這樣處理

Ia a = createA();//經過調用一個函數實現得到a的實例.

當咱們需求再發生更改的時候,只須要改一下函數內的具體實例化就能夠了.

並且,creatA函數內部也可使用反射來實現動態返回想要的類.

這其實就是工廠系列模式中最核心的韻味.雖然工廠方法和抽象工廠在此基礎上進行了抽象和封裝的擴充.

寫到這裏我想起了一篇小文章.

當我在大學的時候，我選了一門「高級」面向對象編程課程。之前歷來沒有接觸過這種知識，這個課程使用SmallTalk這種語言教學，並且教學方式很是特別；第一天，教授給咱們佈置了一個將會貫穿整個4周課程的做業。

咱們很是興奮，由於這是要編寫一個遊戲。一個老式的文字輸入式的冒險遊戲，相似於Zork風格。咱們分紅3人一組，來到教授擁擠的小屋裏。在那裏，教授給了咱們一頁紙，上面寫着一些說明。從那裏返回時咱們幾乎是一路小跑。

而就在咱們剛要出門時，教授把咱們叫了回去(我相信他是特地選了這個最佳時機)：

「哦，我差點忘了。兩個星期後，我會對這個遊戲內容作一些大的修改。大家要繼續按修改後說明開發。」

我跟不少的軟件開發團隊(包括一些軟件產品創始人)說過這個故事，他們的反應幾乎都同樣：

你能在屋裏聽到笑聲。至少是咯咯的笑。常常你還能一些「不會吧」等話
「哦，老兄，這也太沒譜了吧！」
「這教授這麼難爲人嗎——怎麼可能有這樣的任務」
問題就在於，教授並無告訴他將會作什麼樣的修改。只是說會修改一些東西——兩週後。

你認爲咱們該如何去完成這個任務？

咱們開發時到處設防。

「哦，不行——若是教授打算改動這個怎麼辦？」
「也許應該把這裏作成接口——萬一教授要求用不一樣的方式實現它呢？」
「不行——咱們應該把這部分提取出來，這樣，當咱們修改這部分時就不須要改動模塊X了」
這就是咱們的作法。我最想說的是，這是一個很是好的做業任務，它讓我在面向對象編程和Smalltalk方面學到了不少。感謝你，咱們的Davidson教授！

最終，咱們作成了一個很是模塊化的系統，這使對它們的修改變得很容易。當那一天終於到來，當遊戲設計被修改後，咱們經過努力在一天內就按照要求修改了程序，使咱們能順利的接着開發界面和怪獸等很酷的部分。

咱們爲之後的改變而優化系統。由於Davidson教授告訴咱們變化很快就會來到。

不少程序員抱怨客戶需求不斷變化,老闆今天讓改這個明天讓改那個.其實在你踏入行業第一天,你就應該意識到也許需求下一秒就會變化.所以在設計的時候,爲變化留下後路.甚至說趕在客戶/老闆以前意識到變化,並做出調整.沒有人懷疑程序員是一批聰明的人.那麼你只要用心,必定能發現變化.運用設計模式擁抱它.