面向對象

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

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

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

很少說，拿實例說話。

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

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

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

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

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

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

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

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

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

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

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

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