1 SOLID原則
Single responsibility principle 單一責任原則
改的只有一個小的部分，也適合單元測試
解析：單一責任原則指的是一個類只有一項工作，例如一個格式化數據打印的類，類中的成員函數可以有Json格式化輸出函數，String格式化輸出函數，List格式化輸出函數等等。這邊的單一責任就是指這個類的唯一工作就是格式化輸出數據。
第二種原則叫做O-Open Close Principle（開放封閉原則）
對擴展開放，對修改關閉
解析：抽象類不允許被直接創建對象，其他類的特性依舊存在。抽象類的實現應在繼承該類的子類中去具體實現。抽象類中只負責定義該抽象方法。由于abstract 的方法需要在繼承后的子類中實現，因此不可以 與final , private , static 共存。
L – Liskov substitution principle（里氏替換原則）和I – Interface segregation principle（接口分離原則）
機器人不能繼承人的類
類不能繼承不能實現的接口
解析1：SingleResponsibility 是為了解決后續維護中class過于臃腫的原則，InterfaceSegragation 是為了解決面向外部調用者讓其他開發人員更容易明白不同接口的功能區別而總結的原則。
解析2：假設現在我們有一個interface提供給用戶，但是里面有太多用戶不需要的功能，顯得我們的interface過于臃腫；那么這時候我們就要把這個大的接口根據功能再次細分，然后提供給不同的用戶。這就叫接口分離。
解析3：當父類的某些方法不確定時，可以用abstract關鍵字來修飾該方法[抽象方法]，用abstract來修飾該類[抽象類]，一個類中一旦有抽象方法，必須定義成抽象類。子類在繼承父類的時候一定要實現父類中的抽象方法，并且會自動繼承除構造函數以外的Public和Protect方法，子類可以重寫這些方法。此外，子類也可以自定義自身的方法。
最后一個原則是D–Dependency inversion principle（依賴反轉原則）
抽象不應該依賴于具體實現，具體實現應該依賴于抽象，因為如果如果具體實現沒了，你依賴它就會報錯
2 例題和5C解題法
- Clarify
what （提問關鍵字）：
關鍵1：Elevator
有沒有承重不一樣
會不會分客梯和貨梯
關鍵2：Building
是否有多處能搭乘的電梯
how（針對規則來提問）
判斷是否電梯超重
按下按鈕，哪一臺電梯會響應
電梯運行的時候能否按下反向的樓層 - Core Object
以一個Object為基礎，線性的把流程需要的Object寫出來，比如 Request -> ElevatorSystem -> Elevator -> ElevatorButton
確定Objects之間的關系，比如一對多，或者多對一 - UML類圖符號
解析：在UML類圖當中，每個方法和屬性都會用前綴修飾符來表示其訪問級別。若沒有前綴修飾符則代表此方法或屬性屬于Package內都可訪問，在不同Package內不能直接訪問。若有修飾符：'+'表示Public，代表此方法或屬性公開，能在任何地方都能直接訪問；'-'表示Private，代表此方法或屬性私有 ，只能通過類內部訪問；'#'表示Protected，代表此方法或屬性為保護，在同一個Package內可以訪問，在另一個Package內需要通過子類繼承才能進行訪問。 -
Cases
利用之前定義的CoreObject，列舉每個Object對應產生的use case，如：
-
Class
如：
Use cases，對于use case更加詳細地描述這個use case在做什么視頻，針對這個描述去已有的Core Object填充進所需要的信息
解析： 使用ENUM相當于提前定義了一個類只能從一組值當中選擇，比如定義一個ENUM COLOR，可選的值為 RED, YELLOW, BLUE. 這樣的方法和使用String / Integer 做為值相比使得代碼的可讀性大大提升；同時這樣的ENUM告訴編譯器傳遞進來的值只能從紅黃藍三色當中選取，避免錯誤；同樣這個定義過的ENUM可以在任何地方被使用。但ENUM從運行速度上來說和其他做法并沒有太大區別。
使用異常處理來處理特殊的情況。 - Strategy Design Pattern
把策略變為interface，符合依賴翻轉原則
解析：當一個類只做一件事情的時候，它通常會有更少的函數/變量/接口, 使得這個類更容易被理解；同樣，由于這個類只負責一件事，這個類的變化不容易影響到其他的類，使得代碼更易維護，也更容易被其他需要相同功能的地方復用；至于高耦合 (Tighter Coupling)，這其實是在設計當中我們避免出現的事情，它指的是類和類之間有很緊密的關聯，所以SRP其實引導向的是一種好的設計模式，也就是高內聚，低耦合 (High Cohesion， Loose Coupling)。
