物件導向設計的方便性
以前寫過的程式, 雖然會使用函式(function)將通用性的功能包在一起, 不過需要自己設定一些變數, 避免干擾其他程式設定.
看了物件導向的程式範例後, 總算理解: "封裝"不只是把函式分類, 而是透過物件導向語言, 在程式寫成類型後, 語言就會幫忙把程式每次產生的物件分開, 省去寫程式的人自己做標記或加上一堆變數的工作.
比如這兩個月在新工作的其中一個任務, 就是寫一個為民服務統計系統, 在經過幾週的訪談跟取得現有文件後開始分析. 流程還算單純, 就填報人, 核可, 統計; 但是為民服務項目很多樣化, 所以有些以天為單位, 有些以月或季為單位, 有些項目在機關但又有駐點.
所以應用物件導向的設計原則, 後端先把系統用的功能如資料庫連線, 服務管理, 帳號管理, 週期(日, 月, 年), 駐點單位分別建立一個類型.
另外參考MVC結構, 進網站基本上只有一個PHP網頁, 而透過隱藏的參數, 這個網頁再引入其他的網頁內容來顯示.
比如剛開始就是先判斷參數"目前使用者", 推測是否已經登入, 再自動引入登入畫面.
登入後, 依登入者的權限, 顯示相對應的功能, 在填寫服務功能下, 主畫面只有引入服務清單, 然後呼叫服務管理內的判斷是否已經填過, 或已經過期無法填寫, 這判斷就放在服務管理類型下, 每個服務只要直接用 類型::static_function(服務代號,查詢); 就可以了, 實際運作就由 服務管理 這個類型內的動作去處理, 完全不用再考慮到底怎樣處理的, 而 服務管理 類型裡面就包含呼叫資料庫, 也是只有短短幾行, 其他由 資料庫 的類型內的其他程式去處理, 這樣 服務管理 本身就只負責服務相關的處理.
基礎架構規劃好, 實際上寫程式時也就方便多了, 因為填寫資料大概分為表頭與表身存檔, 表頭包括: 期/機關/填寫日/是否鎖定/服務專案, 表身是服務專案內的清單, 以及實際服務人次.
有些服務專案多了駐點, 則評估影響的範圍, 包括填寫網頁內新增第二層清單, 以及服務管理中跟表頭有關的動作, 加上選擇性對駐點的判斷, 程式中有駐點則增加一點動作, 其他程式都不變.
所以主架構完成後, 加上駐點只要一天就完成了, 這就是物件導向程式的方便所在.
