生活中的例子：

很多互聯網公司都是彈性質工作：每天工作8小時，對每天工作8小時這個制度修改是關閉的，但是對於什麼時候來，什麼時候走制度是開放的，早點來早點走，晚點來晚點走，前提是幹嘛8小時工作。

軟體開發最重要的原則：對修改關閉，對擴展開放，開閉原則是其他原則的基礎

下面使用代碼來講解：

使用慕課網的例子來講解

1、先定義一個課程的介面：

2、再定義一個Java課程JavaCourse類，實現課程介面ICourse

3、測試類：

下面是UML類圖（IDEA真神器也）：

假設1024這一天，慕課網有活動了，需要給課程進行打折，怎麼來開發這個需求呢？

我們是不是可以在ICouse這個介面中增加這樣一個打折的方法呢？

如果我們這樣增加，那麼JavaCouse這個類也要進行修改

雖然可以修改，但是有沒有想過一個，就是介面一改，那麼實現這個介面的所有類都需要修改，我們知道有的課程是不需要打折的，而且修改介面一定要慎重又慎重的，因為它是穩定可靠的一個標準，一個協議。

所以我們換另外一種思路：

我們不是1024要打折課程嗎？那我們給打折的課程返回價格的方法這樣修改就行了，但是這樣確實可以獲取打折的價格，但是原來的價格怎麼辦呢？如果課程多豈不是我們要修改很多的類。

解決：

我們可以這樣：定義一個打折的類JavaDiscountCourse去繼承我們要打折的那個類JavaCourse

我們來看現在UML的關係圖：

我們可以看到我們的介面ICourse沒有改變，JavaCourse也沒有改變，我們修改的是應用層的代碼，底層的代碼我們是並沒有修改的，這樣可以很好的防止風險的擴散，因為在開發中的介面是有很多的方法，類中也是有很多的方法，我們輕易修改可能會造成系統的混亂的，越底層的模塊影響越大，越高層的變化影響越小。

使用一個類去繼承原有的類，很好的滿足了設計原則的開閉原則，對

修改的關閉，對擴展的開放。

這裡讓我聯想到，使用MyBatis-逆向工程生成的pojo、mapper文件，因為只能對單表操作，當我們需要多表聯查的時候，就需要自己寫條件，特別是Pojo實體類中，還可能包含其他實體類，這時候我們不建議直接修改MyBatis-逆向工程直接生成的那個Pojo實體類，而是使用一個類去繼承它，去擴展它就行了。

當然了，可能有人會說，我們關聯查詢需要自己手寫Mapper映射文件裡面的查詢操作，這也涉及到了介面綁定對應的介面

不是說開閉原則不能進行修改嗎？

是的，沒錯，但是我們知道規則是人定的，我們一味的遵守規則那也是不好的，要得懂得靈活的變通，這裡介面和映射文件是綁定在一起的，除了它倆就沒有其他的關聯，我們也是可以違反一下規則的嘛，就和現實生活中一樣。

總結：關於開閉原則，我現在理解還是不夠全滅，還是得多實踐，多思考，以後有擴充內容再補充吧。

推薦閱讀：

相关文章