面向對象

如下文章純粹是本身的觀點與對於面向對象的理解,有不妥之處,望指出!算法

初次讀完設計模式以後,感受沒什麼用處,鑑於當時本身仍是初級開發,因此理解的不夠深入;可是,如今深入的理解,設計模式必須得讀,他直接影響的是你的編程思想。數據庫

成天說面向對象面向對象,可是大多數狀況下咱們只是用面向對象的語言寫出面向過程的代碼。咱們一般都是在一個類中寫了不少個方法,而後方法按照通常面向過程的思惟實現需求要咱們實現的功能。長此以往,你會發現,寫代碼真沒沒勁,來回是那幾行,這時候你須要讀讀設計模式,讓本身的代碼更美觀,提升本身系統的可擴展性、可重用性、可維護性。編程

很少說,拿實例說話。設計模式

最近在開發一個關於練習的系統,學生進到系統能夠根據本身的學習狀況練習。學習

咱們只拿出一個系統的核心模塊,加載練習來講。設計

     這個模塊的需求是這樣的,學生會根據本身的學習狀況選擇不一樣的答卷模式,目前咱們系統分爲了3種:簡單、通常、困難;加載這三種類型的試卷的試題時,會根據學生的練習狀況、答題狀況動態的去根據不一樣的算法加載。好吧,需求說道這裏,下面咱們來講實現。對象

     通常咱們會建一個Service,這個Service只是提供加載練習的服務,裏面可能會有3個方法,加載簡單試卷、加載通常試卷、加載困難試卷;blog

      當咱們在寫加載試卷的方法的時候,可能會先獲得學生的練習狀況,再獲得學生的答題狀況,再根據這些內容去庫裏找到對應難度的試題。當咱們須要查找數據庫時,可能會調用Dal層的增刪改查的方法。完了以後會把以上所作的操做拼接成一個流程,最後會獲得一些試題列表返回到前臺。繼承

      那麼問題來了,若是咱們又增長了一種難度的試卷,是否是咱們會再寫個方法,再操做一遍以上的內容,再整合成一個流程......接口

      你可能會說,這中間不少方法,均可以公用啊,好吧,若是當我獲取簡單試卷的方法時獲取答題狀況的算法改了,那麼是否是至關於整個獲取試卷的Service都改了,由於咱們修改的是公用的核心方法。

    針對以上問題,咱們首先應該想到設計模式,設計模式的目標就是提升系統的可擴展性、可重用性、可維護性。

    分析後你會發現,其實獲取試卷的流程同樣,不同的只是算法而已,那麼咱們能夠抽象這個算法爲一個接口,不一樣的試卷算法繼承自這個接口,這樣咱們修改某個算法時,不會影響到其餘的算法。UML以下

那麼,不論獲取什麼試卷,流程是同樣的,咱們就能夠把這些流程封裝成一個接口,咱們只要獲取試卷,調用這個接口便可,不一樣的是上面說的算法不一樣而已,咱們就又出來一個接口:

這樣咱們就解決了上面遇到的問題。

綜上,本篇文章只是一個例子,旨在引導你們拿到需求先分析,運用面向對象的思想來完成咱們的需求。

相關文章
相關標籤/搜索