您好,登錄后才能下訂單哦!
開放-封閉原則(OCP:The Open-Closed Principle)
開放-封閉原則:軟件實體(類,模塊,函數等等)應該是可以擴展的,但是不可修改的。
設計的目的便在于面對需求的改變而保持系統的相對穩定,從而使得系統可以很容易的從一個版本升級到另一個版本。
大家可能都有這樣的體會,要滿足各種各樣的客戶,并且客戶的需求經常變化,程序員就是這樣的辛苦命,整天改過來改過去,特別用一些非面向對象的語言寫的代碼,函數的參數變得越來越長,里面的Case情況慢慢增加,函數變得很大。軟件幾年之后就變得難于理解和維護,軟件的生命周期好像就要終止。如果能夠擴展模塊的功能,同時又不修改原來已經測試通過的代碼,那多好啊!
這完全是可以實現的,關鍵是抽象。把可能的變化用抽象來隔離它。面向接口編程,而不是面向對象編程,能增強程序的靈活性;如Client類調用Server類,如果我們希望Client對象使用另外一個不同的Server對象,就必須修改Client中使用Server類的地方;如果Client調用Server的接口就可以避免這種修改,只要生成新的接口實現類,修改Main等初次使用新子類的地方而不需要修改Client類;使用Strategy模式和Template Method模式是滿足OCP的最常用方法。
如果需要適應某種變化就需要對這種變化進行抽象,會增加程序的復雜度。所以設計人員應該熟悉業務和了解客戶需求,預測到需要進行抽象的變化。
敏捷建模不建議提前進行各種假想的變化抽象,而是當變化發生第一次的時候抽象這種變化,以后同樣的變化就變得很容易。對代碼進行重構以保持良好的結構是很重要的,每次抽象都不應該使軟件變得越來越僵化。這是非面向對象的語言不具備的優勢
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。