1.0 OCP原則
即開放關閉原則，指設計應該對擴展開放，對修改關閉。軟件設計完要留有升級接口和升級空間。
如打怪,木劍打怪減血20，鐵劍打怪減血40，聖劍打怪減血80。如果寫一個方法，用if else 結構去寫，會違反OCP原則。當有新武器加入的時候，要修改打怪的If else代碼。而應該使用擴展完成，避免修改已有代碼。
一般來說，當一個方法裡面出現冗長的if…else或switch…case結構，且每個分支代碼業務相似時，往往預示這裡應該引入多態性來解決問題。而這裡，如果把不同武器攻擊看成一個策略，那麼引入策略模式（Strategy Pattern）是明智的選擇。
Tip：策略模式，英文名Strategy Pattern，指定義算法族，分別封裝起來，讓他們之間可以相互替換，此模式使得算法的變化獨立於客戶。
參考：依賴注入那些事兒 --T2噬菌體
2.0 DRY原則
DRY是“Don't Repeat Yourself”的縮寫。意思是說，在一個設計裡，對於任何東西，都應該有且只有一個表示，其它的地方都應該引用這一處。這樣需要改動的時候，只需調整這一處，所有的地方就都變更過來了。
運用DRY原則的時候，有一個很微妙的事情是要認真判別兩樣東西是否是一回事。有時候也有“兩樣東西現在碰巧看起來是一樣的，但是並不能保證將來始終都一樣”的情況。這種時候，很可能就有制造一點表面上的重復的必要了。
其他原則,來自百度百科--
1.避免重復原則(DRY - Don’t repeat yourself)
編程的最基本原則是避免重復。在程序代碼中總會有很多結構體，如循環、函數、類等等。一旦你重復某個語句或概念，就會很容易形成一個抽象體。
2.抽象原則(Abstraction Principle )
與DRY原則相關。要記住，程序代碼中每一個重要的功能，只能出現在源代碼的一個位置。
3.簡單原則(Keep It Simple and Stupid )
簡單是軟件設計的目標，簡單的代碼占用時間少，漏洞少，並且易於修改。
4.避免創建你不要的代碼 Avoid Creating a YAGNI (You aren’t going to need it)
除非你需要它，否則別創建新功能。
5.盡可能做可運行的最簡單的事(Do the simplest thing that could possibly work)
盡可能做可運行的最簡單的事。在編程中，一定要保持簡單原則。作為一名程序員不斷的反思“如何在工作中做到簡化呢?”這將有助於在設計中保持簡單的路徑。
6.別讓我思考(Don’t make me think )
這是Steve Krug一本書的標題，同時也和編程有關。所編寫的代碼一定要易於讀易於理解，這樣別人才會欣賞，也能夠給你提出合理化的建議。相反，若是繁雜難解的程序，其他人總是會避而遠之的。
7.開閉原則(Open/Closed Principle)
你所編寫的軟件實體(類、模塊、函數等)最好是開源的，這樣別人可以拓展開發。不過，對於你的代碼，得限定別人不得修改。換句話說，別人可以基於你的代碼進行拓展編寫，但卻不能修改你的代碼。
8.代碼維護(Write Code for the Maintainer)
一個優秀的代碼，應當使本人或是他人在將來都能夠對它繼續編寫或維護。代碼維護時，或許本人會比較容易，但對他人卻比較麻煩。因此你寫的代碼要盡可能保證他人能夠容易維護。用書中原話說“如果一個維護者不再繼續維護你的代碼，很可能他就有想殺了你的沖動。”
9.最小驚訝原則(Principle of least astonishment)
最小驚訝原則通常是在用戶界面方面引用，但同樣適用於編寫的代碼。代碼應該盡可能減少讓讀者驚喜。也就是說，你編寫的代碼只需按照項目的要求來編寫。其他華麗的功能就不必了，以免弄巧成拙。
10.單一責任原則(Single Responsibility Principle)
某個代碼的功能，應該保證只有單一的明確的執行任務。
11.低耦合原則(Minimize Coupling)
代碼的任何一個部分應該減少對其他區域代碼的依賴關系。盡量不要使用共享參數。低耦合往往是完美結構系統和優秀設計的標志。
12.最大限度凝聚原則(Maximize Cohesion)
相似的功能代碼應盡量放在一個部分。
13.隱藏實現細節(Hide Implementation Details)
隱藏實現細節原則，當其他功能部分發生變化時，能夠盡可能降低對其他組件的影響。
14.迪米特法則又叫作最少知識原則(Law of Demeter)
該代碼只和與其有直接關系的部分連接。(比如：該部分繼承的類，包含的對象，參數傳遞的對象等)。
15.避免過早優化(Avoid Premature Optimization)
除非你的代碼運行的比你想像中的要慢，否則別去優化。假如你真的想優化，就必須先想好如何用數據證明，它的速度變快了。
“過早的優化是一切罪惡的根源”——Donald Knuth
16.代碼重用原則(Code Reuse is Good)
重用代碼能提高代碼的可讀性，縮短開發時間。
17.關注點分離(Separation of Concerns)
不同領域的功能，應該由不同的代碼和最小重迭的模塊組成。
18.擁抱改變(Embrace Change)
這是Kent Beck一本書的標題，同時也被認為是極限編程和敏捷方法的宗旨。
許多其他原則都是基於這個概念的，即你應該積極面對變化。事實上，一些較老的編程原則如最小化耦合原則都是為了使代碼能夠容易變化。無論你是否是個極限編程者，基於這個原則去編寫代碼會讓你的工作變得更有意義。
