面向物件設計（OOD）七大原則
阿新 • • 發佈：2019-01-09
這個原則是由Bertrand
Meyer大師在1988年提出的，那時候我才1歲。這個原則是這樣定義的：
Software entities should be open for extension,but closed for modification。多簡單啊？！這個原則的意思大概是說：軟體對擴充套件應該是開放的，對修改應該是關閉的。說的更通俗點兒，就是說我們開發了一個軟體，應該可以對它進行功能擴充套件（開放），而在進行這些擴充套件的時候，不需要對原來的程式進行修改（關閉）。
各位，如果我們有經歷一段時間的開發，會發現，一個軟體的程式碼設計，如果能做到對功能擴充套件，對修改關閉是多麼棒的事兒。這意味著這個軟體維護的穩定性會大大提高，因為對修改關閉嘛，所以之前的程式碼，不需要太多的修改，我們曾經都做過全文搜尋複製替換部分檔案的事情，或者在好多個檔案中重複的修改某段程式碼。如果我們的軟體編碼能按照對擴充套件開發，對修改關閉的原則去編寫，盡力的讓這個原則更好的體現在軟體設計中，這就是一個非常棒的設計了。
總結一下，如果按照OCP原則，軟體設計開發中，會有如下的優點：
1.在軟體可用性上，非常靈活。你可以在軟體完成對軟體進行擴充套件，加入新的功能。這樣，這個軟體就可以通過不斷的增加新模組滿足不斷變化的新需求！
對OCP的實現，主要用到的就是抽象。各位，你們在編寫程式碼的時候，會不會經常使用抽象的思想呢。一定要用上抽象的思想去寫程式碼。把系統所有可能的行為抽象為抽象底層，這些抽象類規定出所有具體的類必須提供的方法，這些作為系統設計的抽象層。所以使得在任何可擴充套件的情況下，系統的抽象層不需要修改。同時，我們也可以從抽象層再派生出其他的抽象類來修改或擴充套件系統的行為，因此，對於可變部分，是可以擴充套件的。
我們也很容易想到，在一開始進行軟體設計的時候，把所有的東西都面面俱到的考慮到是不可能的（有時候也不合適）。所有可變的東西都寫入到抽象底層是不可能的。因此，開閉原則很難被完全實現。只能在某些模組，某些程度，某個限度內使用這個原則。所以說，OCP具有理想主義的色彩，是OOD設計的終極目標。因此，對OCP的設計原則，許多OOD大師都費盡心思，研究OCP的實現方式。很多原則，如：里氏代換原則、合成複用原則，依賴倒轉原則，介面隔離原則，抽象類，迪米特法則等，都可以看作是OCP的實現方法。
Software entities should be open for extension,but closed for modification。多簡單啊？！這個原則的意思大概是說：軟體對擴充套件應該是開放的，對修改應該是關閉的。說的更通俗點兒，就是說我們開發了一個軟體，應該可以對它進行功能擴充套件（開放），而在進行這些擴充套件的時候，不需要對原來的程式進行修改（關閉）。
各位，如果我們有經歷一段時間的開發，會發現，一個軟體的程式碼設計，如果能做到對功能擴充套件，對修改關閉是多麼棒的事兒。這意味著這個軟體維護的穩定性會大大提高，因為對修改關閉嘛，所以之前的程式碼，不需要太多的修改，我們曾經都做過全文搜尋複製替換部分檔案的事情，或者在好多個檔案中重複的修改某段程式碼。如果我們的軟體編碼能按照對擴充套件開發，對修改關閉的原則去編寫，盡力的讓這個原則更好的體現在軟體設計中，這就是一個非常棒的設計了。
總結一下，如果按照OCP原則，軟體設計開發中，會有如下的優點：
1.在軟體可用性上，非常靈活。你可以在軟體完成對軟體進行擴充套件，加入新的功能。這樣，這個軟體就可以通過不斷的增加新模組滿足不斷變化的新需求！
對OCP的實現，主要用到的就是抽象。各位，你們在編寫程式碼的時候，會不會經常使用抽象的思想呢。一定要用上抽象的思想去寫程式碼。把系統所有可能的行為抽象為抽象底層，這些抽象類規定出所有具體的類必須提供的方法，這些作為系統設計的抽象層。所以使得在任何可擴充套件的情況下，系統的抽象層不需要修改。同時，我們也可以從抽象層再派生出其他的抽象類來修改或擴充套件系統的行為，因此，對於可變部分，是可以擴充套件的。
我們也很容易想到，在一開始進行軟體設計的時候，把所有的東西都面面俱到的考慮到是不可能的（有時候也不合適）。所有可變的東西都寫入到抽象底層是不可能的。因此，開閉原則很難被完全實現。只能在某些模組，某些程度，某個限度內使用這個原則。所以說，OCP具有理想主義的色彩，是OOD設計的終極目標。因此，對OCP的設計原則，許多OOD大師都費盡心思，研究OCP的實現方式。很多原則，如：里氏代換原則、合成複用原則，依賴倒轉原則，介面隔離原則，抽象類，迪米特法則等，都可以看作是OCP的實現方法。