我一直以為，世間萬事萬物，都存在著某種規律性的東西，只不過，有的已經被發現，有的還在人們的探索過程中，等待被發現，軟體設計亦然。其實，生活中的很多東西，是可以相通的（比如心和心）。

　　不是嗎？那本很有名的書《建築的永恆之道》，正是歸納出了長久以來，在人們漫長的經歷中摸索出來的有關建築的一些規律性的東西。然而，它卻不僅止於建築，它還可以延伸至其他諸多領域。我們可以發現，很多精彩的軟體設計模式，也是源於此書的思想，這也正是此書的思想光輝光彩照人的原因所在。現在，它的聞名似乎不在建築業，而在軟體業了，正所謂“失之桑榆，取之東隅”。

　　好了，言歸正題。軟體設計的六大原則是什麼呢？這也是無數軟體設計“先烈”前撲後繼（呵呵，說“先烈”似乎悲壯了點:-)），歷經磨難而總結出來的“葵花寶典”。慢著，說“葵花寶典”似乎不太適合，改用“內功心法”吧。那麼，軟體設計的六大內功心法是什麼呢？

　　內功心法一：開閉原則

不知為啥，一提到這個心法，便想到一扇門，可以讓什麼進去，而不讓什麼進去。當然，這絕不是“華人與狗不得入內”的那扇門（強大的中國已經不是過去的中國了，我為中國人而驕傲）。這扇門是，對擴充套件開放，對修改關閉。這句話的意思是，你不要動我的乳酪，你不要動我已有的東西，你可以新增新的東西給我，或者替換我的東西。由此聯想到Spring中，“依賴注入”的一種實現方式：通過配置介面的實現類而注入，如果業務邏輯發生了變化，只需要提供新的實現加以替換就可以了，你不需要動她原有的東西，以免傷及無辜。

　　內功心法二：里氏代換原則

這個原則就是：在任何基類出現的地方，子類都可以出現。面向物件程式設計的一大特性是：多型。正是多型這個特性造就了很多優秀的設計模式。一般而言，基類總是更一般化的東西，比較少涉及細節以及具體實現。如果遵循此原則，我們就能更好地利用多型的特性，使用一個基類的引用（這個引用可以指向子類），大膽地呼叫方法，而不必過度地關心其實現細節。歪解：在任何爸爸出現的地方，兒子都可以出現。爸爸能做的事，兒子也能做，而且會做得更好、更細緻、更有針對性。有時候爸爸只是告訴兒子去做什麼，而怎麼做是兒子自己的事情。（爸爸就是爸爸，主要職責是發號施令，呵呵）

　　內功心法三：依賴倒轉原則

此原則為：要儘量依賴抽象，不依賴實現。我想熟悉Spring的同仁們應該對此原則有著更深的體會。此心法與心法二相輔相成，有異曲同工之妙。感悟：似乎上層的領導更多的依賴抽象，而底層的員工，更多的依賴實現。正是因為日常我們更多地關心實現細節，而被紛繁的細節變化所累。依此心法修煉，你就能提高層次，從實現的變更導致的煩惱和痛苦中解脫出來。

　　內功心法四：合成/聚合複用原則

很多初學武功的人，在只是學到一點皮毛之時，往往自以為已經得到武功的精髓，處處表現或找人比試。而初學面向物件程式設計的許多人，最初瞭解且能留下比較深印象的恐怕就是“繼承”這個概念了，彷彿繼承便是面向物件的精髓了。於是乎，程式設計時狂用繼承，生成一系列像“麻辣串”似的類體系。而前人的實踐經驗卻證明：要儘量多用合成或聚合，少用繼承

    　內功心法五：迪米特原則

這個原則的主要含義為，一個實體要儘可能少與其它實體發生作用或聯絡。換句話說，與你無關的東西，你知道得越少越好，不要和陌生人說話。事實上，它和最少知識原則殊途同歸。

　　內功心法六：介面隔離原則

意思是說，要多建立些功能定義相對獨立的小介面，避免龐大的總介面。每一個介面好比一種角色；每個角色都應該有明確和有限的職責，不該做的事不做，該做的就一定要做好。

　　以上所謂的內功心法，非經長期實踐修為，而不能洞明其妙也。