本文是對敏捷軟件開發(fā)第九章開發(fā)-封閉原則的學(xué)習(xí)筆記沾歪。
一句話，軟件實(shí)體應(yīng)該是可擴(kuò)展但是不可修改的饲齐。
- 對于擴(kuò)展是開放的
- 對于修改是封閉的
比較經(jīng)典的例子就是代碼中如果有鏈?zhǔn)降膇felse語句或者switch的語句的處理爽待。這個(gè)也可以說是軟件開發(fā)中大家都會遇到的問題，我個(gè)人也沒什么好的方法
還是具體問題具體分析遏考，遇到可以抽象的慈鸠，可以抽象出subclass來處理，如做不到可以嘗試使用map代替條件做處理灌具。
可以參考下這個(gè)鏈接：https://sourcemaking.com/refactoring/smells/switch-statements
如何根據(jù)OCP原則設(shè)計(jì)系統(tǒng)青团？
實(shí)際上對于軟件工程中的很多的理論都是需要開發(fā)者的經(jīng)驗(yàn)支持的，就比如今天說的ocp咖楣，需要開發(fā)者對于他設(shè)計(jì)的模塊應(yīng)該對哪種變化封閉做出選擇督笆，因?yàn)槟K是無法完全做到封閉的，軟件是變化的诱贿。并且過度設(shè)計(jì)和不設(shè)計(jì)一樣難以接受娃肿。
書中有個(gè)繪制圖形的例子，從一開始對每個(gè)形狀做判斷需要使用switch開始珠十，到抽象出形狀類料扰，再需要對各種形狀繪制的排序需求。第一次變化是遵循了OCP原則焙蹭，開放了接口晒杈，封閉了每個(gè)圖形內(nèi)的變化。到第二個(gè)變化時(shí)候發(fā)現(xiàn)原先的抽象并不能滿足這次需求的變化（不能做到按照需求根據(jù)順序繪制不同類型圖形）孔厉。這里也引出了一個(gè)問題：需求的變化而引起設(shè)計(jì)的變化（并且這個(gè)也是無法避免的）拯钻。從軟件開發(fā)角度上說帖努，我們可以做到針對第一種變化，抽象说庭，確保不再被此類問題引起代碼僵化然磷。而對于第二種變化：主動嘗試刺激變化，包括短周期迭代刊驴，測試驅(qū)動姿搜，首先開發(fā)最重要的特性，頻繁發(fā)布軟件引起需求變化盡早到來捆憎。
