OO設計原則

OO的設計很多人都知道

 

•Encapsulation (封裝)

–Encapsulate member into a class

–Modularity

–Information hiding

–Reusing

•Inheritance (繼承)

–Override

–Extension from super classes

•Polymorphism (多型)

–Re-implement interfaces from super classes

–Overload

 

但是, OO設計的原則, 卻很少人提及...

•SRP：Single Responsibility Principle(單一職責)

•OCP： Open Closed Principle(開放封閉)

•DIP ： Dependency Inversion Principle(依賴倒轉)

•ISP：Interface Segregation Principle(介面隔離)

•LSP ： Liskov Substitution Principle(替換)

•CARP：Composite/Aggregate Reuse Principle(合成/聚合複用)

•LoD ： Law of Demeter(迪迷特-最小最少認知)

其中最容易理解, 卻也最難做到的, 正是單一職責及開放封閉原則

第一, 何謂單一職責!?

一個class不該擁有兩種以上的能力(功能), 也就是說, 一個class只做一件事, 當然這件事的大小, 可以再分割下去, 直到寫程式不再是一件難事就行, 但是如果這個class慢慢的被加大, 那就該考慮是不是該用refactor方法, 再分割這個class, 但為什麼這很難達成呢?

答案是:偷懶, 每次加一點code, 就像青蛙在水褚被煮一樣, 你不會有所感覺, 直到有一天真的很大了, 也難分割了, 就以就放著讓他爛...

最好的解法: 當然有, 但..要看到一個class加了一個新的功能時(不影響主功能)就分割, 可能要有點經驗的人才知道這樣的分法是好一點的, 有的class很小, 有的class很大, 寧可讓所有的class都是小的再結合成大的, 也千萬不要讓class長大再refactor, 如果你有maintain很大型的code經驗, 你知道我在說什麼

第二, 何謂開放封閉原則!?

一段程式碼, 應該對於修改採取封閉, 對新增功能採取開放..

也就是我不允許別人修改我寫完的code, 但是對於要新加的功能是可以的, 最好的做法就是繼承, 當然這也不是解決"開放封閉原則"最好的方法, 最好的方法是程式寫好都不要動, 所有的功能都放在另一個地方去指定, 把這功能都組合起來就可以達到你想做的事情, 但....

答案是: 不可能

在設計的最初這件事情不可能達成, 但設計後總有design document, 可以指定哪些東西不得修改(這是這個程式最主要的功能, 沒有這功能其他都免談的地方), 也就是不可修改程式必須的功能, 但對於擴充功能是要可以的..

可是可是...這個也很難達成是吧...一個巨型的計劃中, 所有的功能不但可能改變, 更有可能被要求加入和先前設計完全不同的功能..這時就得輪到主管出馬了

總之問題的發生在於人對於"程式"的想法..如果有不能解決的, 還是得溝通一下...

謹記在心, 如果有天你發現加了新的功能要改到原有的code, 或是要改到很多地方的code...那你一定是違反了開放封閉原則了