面向對象程序設計學習日記
面向對象程序設計學習日記
持續更新(可能)，更新時間不限，催更不管，腰斬就跑（逃～）
Date：2018.5.1(Elevator_V1.1)
前言
五一節每年都過得相當委屈，全國勞動者放假，學生雖然跟著放假卻因為勞動者都不足，不少服務不是暫停就是加價，所以放假也只能老實呆在家裏宅著。
但是！今年五一節是我這一生過得最憋屈的一次，QQ列表裏的人幾乎全去玩了，就我一個沒人約，孤獨的宅在家裏刷空間？？然而打開空間就又是一股滿滿的現充之風鋪面而來，還給不給死宅留條活路了(心碎.jpg)。
五一沒人約，B站UP主們也放假視頻也沒更新，在家閑著沒事，想起自己的代碼各種無意義的變量名亂飛，類成員權限淩亂不堪，是時候靜下心重構自己的代碼了。
變量名命名規範
重構之前，首先就先把自己淩亂不堪的變量名改了。由於高中競賽那會兒留下的壞毛病，什麽變量都是想到就定義，管他最後有用沒用先定義了再說。這顯然是不符合編寫大型工程的。於是在網上我找了找相關的C++編碼規範，找到了這麽一篇規範指南：
(Google開源項目風格指南)[http://zh-google-styleguide.readthedocs.io/en/latest/contents/]
指南中指出，變量名的命名應該遵循易於理解變量存儲的數據的意義，尤其在合作編程的過程中，一個簡單明了的變量能使合作夥伴更快的了解變量在一段代碼中的作用，事半功倍。
於是就照著它所介紹的命名規範(駝峰法)開始了艱辛的修改歷程。
類成員管理
依照封裝原則，重構的第一步就是先把所有成員變量私有化。封裝的好處有很多，淺顯一點就是防止用戶在訪問的時候修改成員變量的值，也可以讓一些內部成員變量不公開。總之，C++類建議我們私有化成員，公開接口保證成員與外界的聯系，我便照著這條路徑開始重構。
然而，成員私有化，才是這次重構噩夢的開端。，當我將“public“改為“private“的一剎那，VS code便提示我竟然有99+error。。。看來接下來的過程並不好走啊。。
??
首先，之前我將電梯分為三個模塊——Time（時間）、Floot（樓層）、People（乘客），時間模塊管理時間信息，樓層模塊管理運行信息，乘客模塊管理乘客數量，分塊管理數據。
接下來，以最簡單的修改方案為例，留下"r_x"和"w_x"作為訪問x成員變量的基礎接口——r：讀取數據，w：修改數據。這樣，基本的數據接口就完成了，外部訪問時，就調用r_x()成員函數，而如果要修改某一值，就調用w_x()成員函數。
但是，這樣的接口顯然不能滿足大量的數據交換，於是下一步便是將可能需要實現的步驟以成員函數進行整合，比如電梯到達後需要更新時間、樓層、人數，那麽直接調用arrive()成員函數即可，這樣可以簡化接口，並且可以封裝個別數據不允許用戶單獨修改，防止錯誤的修改操作。
??
OK，電梯成員成功封裝。然後我考慮到，我是利用dfs作為我的策略算法進行運行決策，而調用dfs之前先經過一個主要的主函數進行預處理，以及在dfs時也會調用決策函數plan()，因此我並不想讓外界直接調用dfs()和plan()函數。這麽一來，我想到可以建立一個class Run來封裝策略函數，保留總調度函數作為接口，這樣外界就只能調度這個開放的接口了。
通過以上四步重構，我自認為封裝性做到了比較好的效果，因此類管理重構便到此結束。
類圖：
總結
我自以為自己的代碼已經做到了一半的面向對象的編程習慣了，然而向@Stolf一番請教後被指出：
你只是學了語法，沒有學到思想。這個程序還是沒能脫離面向過程的編程風格，一點面向對象的點都沒抓到
由於我之前寫的代碼完全是依照面向過程進行編程，而且因為我懶，所以也沒有直接推掉原來的代碼重構，這導致了這次的重構是不完全的重構，甚至說不上是重構代碼。因此，它確實沒能脫離面向過程的牢籠。雖然是一個幾乎失敗的工程，但是作為初次個人理解面向對象並試水的過程，從中學到了不少東西。看來得找個時間完全重構一波了啊。
留下Stolf大佬的一句名言：
用心去學，學會很快的。看看別人的源代碼，自己學著寫寫小工程，你每一個失敗的工程都能使你收獲很多。——@Stolf
To Be Continue(?)
面向對象程序設計學習日記