底層模塊的變更，必然有高層模塊的耦合，開閉原則就是要減少變更的擴散性。
而且接口是與其他模塊交流的
契約，修改契約就等於讓其他模塊修改。因此，接口或抽象類一旦定義，就應該立即執行，
不能有修改接口的思想。
不輕易動接口，接口就是契約，業務變更時不應輕易動接口，如果變更可以通過拓展完成的話
這樣只需要在需要變化的業務模塊中改變下實現類就好。
然后開發中也要保持歷史代碼的純潔性，減少對歷史代碼的修改，就能提高系統的穩定。
開閉原則應用
對修改關閉，對增加開放
比方說
1.開閉原則對測試的影響
比較重要的方法的測試方法甚至有十多種， 而且
單元測試是對類的測試， 類中的方法耦合是允許的， 在這樣的條件下， 如果再想着通過修改
一個方法或多個方法代碼來完成變化， 基本上就是痴人說夢
： 假設修改某段已經寫好的底層代碼。這個底層代碼被應用的業務場景少還好，如果它出現在很多個業務場景下了，那就需要檢查多個業務場景是否正確運行。
查看正確運行會用到測試用例，如果方法修改了參數什么的，就要在多個測試用例中改，改了這個還可能影響到別的。所以不要輕易修改老代碼， 但可以拓展
2. 開閉原則可以提高復用性
在面向對象的設計中， 所有的邏輯都是從原子邏輯組合而來的， 而不是在一個類中獨立
實現一個業務邏輯。 只有這樣代碼才可以復用， 粒度越小， 被復用的可能性就越大。
那怎么才能提高復用率呢？ 縮小邏輯粒度， 直到一個邏輯不可再拆分
為止。
這在項目中的反面體現就是加一個東西得在一堆地方+，改一個東西得在一堆地方改。如果把粒度設計的很細，這樣大家都能用到這個小工具，改的時候直接改一個地方就好。