隱喻（metaphor）的力量是強大的，在計算機的世界裡面，我們已經習慣使用各種各樣真實世界的事情來和軟體開發中的概念進行比對。
比如，軟體構造過程的建築隱喻，植物生長隱喻。meyer的契約式設計（design by contract）使用客戶與**商之間的合同、契約來比喻軟體系統中類的使用與實現之間的關係，從而驗證類的正確性在於類的實現需要滿足契約，系統的正確性在於類的使用同時也滿足契約，而契約是從類的規格說明所推導而出的。
下面是對軟體構造過程的乙個隱喻，把軟體開發過程中的需求、業務分析，系統分析，系統設計，實現和測試等比喻作福爾摩斯式的推理過程。
下面是福爾摩斯**「跳舞的小人」中的一段：
福爾摩斯一聲不響地坐了好幾個鐘頭了。他彎著瘦長的身子，埋頭盯住他面前的乙隻化學試管，試管裡正煮著一種特別惡臭的化合物。他腦袋垂在胸前的樣子，從我這裡望去，就象乙隻瘦長的怪鳥，全身披著深灰的羽毛，頭上的冠毛卻是黑的。 他忽然說：「華生，原來你不打算在南非投資了，是不是？」 我吃了一驚。雖然我已習慣了福爾摩斯的各種奇特本領，但他這樣突然道破我的心事，仍令我無法解釋。 「你怎麼會知道？"我問他。 他在圓凳上轉過身來，手裡拿著那支冒氣的試管。從他深陷的眼睛裡，微微露出想笑出來的樣子。 「現在，華生，你承認你是吃驚了，"他說。 「我是吃驚了。」 「我應該叫你把這句話寫下來，簽上你的名字。」 「為什麼？」 「因為過了五分鐘，你又會說這太簡單了。」 「我一定不說。」 「你要知道，我親愛的華生，"他把試管放回架子上去，開始用教授對他班上的學生講課的口氣往下說，「作出一串推理來，並且使每個推理取決於它前面的那個推理而本身又簡單明瞭，實際上這並不難。然後，只要把中間的推理統統去掉，對你的聽眾僅僅宣布起點和結論，就可以得到驚人的、也可能是虛誇的效果。所以，我看了你左手的虎口，就覺得有把握說你沒有打算把你那一小筆資本投到金礦中去，這真的不難推斷出來。」 「我看不出有什麼關係。」 「似乎沒有，但是我可以馬上告訴你這一密切的關係。這一根非常簡單的鏈條中缺少的環節是：第一，昨晚你從俱樂部回來，你左手虎口上有白粉；第二，只有在打撞球的時候，為了穩定球桿，你才在虎口上抹白粉；第三，沒有瑟斯頓作伴，你從不打撞球；第四，你在四個星期以前告訴過我，瑟斯頓有購買某項南非產業的特權，再有乙個月就到期了，他很想你跟他共同使用；第五，你的支票簿鎖在我的抽屜裡，你一直沒跟我要過鑰匙；第六，你不打算把錢投資在南非。」 「這太簡單了！"我叫起來了。 「正是這樣！"他有點不高興地說，"每個問題，一旦給你解釋過，就變得很簡單。這裡有個還不明白的問題。你看看怎樣能解釋它，我的朋友。"他把一張紙條扔在桌上，又開始做他的分析。
推理過程從基本事實出發，通過每一步簡單的推導，最後得出結論，像下圖：
用上面的推理過程來比喻軟體開發，我們從客戶的需求（基本事實）出發，通過各種各樣的分析和推理，設計出各式各樣的中間的抽象模型，比如業務模型，用例模型，分析模型，設計模型等（推理事實），最後通過編碼實現構造出最終的系統（結論）。
那麼測試呢，軟體開發需要對各種抽象模型做概念驗證，對最終的系統做功能測試。與之相對應，在推理過程中，我們也需要蒐集證據對我們的推理事實和結論進行驗證。
最後在推理中，我們抽掉中間的推理過程，只保留起點和結論就能營造出誇張的戲劇性的效果。而在軟體開發中，如果中間的分析設計過程沒有記錄，各種抽象模型沒有保留，只有初始的客戶需求和最後的系統，一樣也能營造出類似驚異的效果，變成維護者的噩夢 ^_^
軟體構造筆記 第一章 軟體構造的視角和質量目標
2 執行視角 run time 2 軟體構造是檢視間的轉換 2 軟體構造的質量目標 2 軟體構造的5個目標 多維度視角 軟體構造 檢視間的轉換 學習目標 軟體系統 程式 資料 文件 規約等 開發視角關注 開發 瞬時 視角 邏輯上程式塊的組織，包含詞彙 語法 如ast 語義 如class diagra...
軟體構造 第二章 軟體構建的過程和工具（1）
一 軟體的生命週期和配置管理 1.軟體的生命週期 1 從0至 1 計畫 確定領域 分析 轉換使用者需求 設計 架構 語言的使用 實行 編寫軟體 測試 檢驗功能 維護 延長至計畫壽命 2 從1至 0 軟體的更新與老化 不同軟體之間相互取代演化 3 經典軟體模型 兩個基礎型別 線性 迭代 瀑布模型 線性...
關於建構函式和析構函式的隱式呼叫
一 首先是最基本的呼叫 class test public test cout default constructor default constructor default destructor 二 在形參值傳遞時的呼叫 class test public test cout default co...