設計沒有標準，模式充滿變化，我們對設計與模式的**，就是希望能從沒有標準的設計中體驗設計的樂趣，從充滿變化的模式中尋求問題的解決之道。
我這裡所謂「設計沒有標準」，其實並非沒有標準，現實是設計的標準實在太多了。我們都希望找到最好的設計方案，然而什麼是最好，每個人都有自己的「哈姆雷特」。滿足客戶需求的設計就是最好的，這個結論我想不會有人反對，前提是，怎樣通過設計來滿足客戶需求？
計畫的設計和演進的設計
通常來說，軟體設計不外乎兩種方式：計畫的設計和演進的設計。很多人看來，計畫的設計更符合工程學的理念。如果你要建一間茅屋，那麼你只需夯好土牆，再胡亂堆放一些茅草置於屋頂之上就可以了。然而，如果要你建一座蘇州的拙政園，就必須事先有計畫的設計了。**應該堆放假山，**應該開闢池塘，亭子的形狀，院落的分布，乃至於園內的一花一木，無不需要獨具匠心。軟體設計也是如此，且過之而無不及。接手專案的時候，首先考慮的不是編碼，而是考慮整個系統的架構，根據需求考慮系統中的重大問題。模組的功能，模組間的關係和系統分布的層次，都需要匠心獨運，從乙個抽象的層面來考慮。
演進的設計恰好與之相反，它是一種漸進的過程。它並不要求前期的設計有多麼的完美，實現的需求有多麼的完整，你只需要把現階段考慮的問題編碼實現就可以了，隨著演進的深入，編碼也會隨之而修正，最後設計會逐漸豐滿起來，經過一系列的方法，最後的設計也漸趨完美。
你也許會認為「演進的設計」如此的簡陋與平庸。沒有計畫，只會令設計一團遭。但我需要提醒你的是，雖然都是工程學，軟體的設計並沒有建築設計那麼簡單。因為，你很難在設計之初，考慮到客戶的全部需求，甚至於實現未來的擴充套件。在設計一開始，你能確信：
你對客戶的需求都理解了嗎？
你能確定客戶的需求不再變化嗎？
你設計的軟體架構真的能滿足需求嗎？
是的，你無法給出肯定的回答。總之我在這裡不是想說服每個人，要採取哪一種設計方式。事實上，我也面臨抉擇的困難。
過度設計，還是簡單設計？
kent在《解析極限程式設計——擁抱變化》中為簡單系統制定了四個評價標準，依次為（最重要的排在最前面）：
通過所有測試；
體現所有意圖；
避免重複；
類或者方法數量最少；
這些標準寫出來簡單，要根據這個標準來實現，就不是那麼容易的事了。我相信，軟體設計人員都希望自己的設計盡可能簡單。然而，在設計時，我們不僅僅要考慮軟體的功能，我們還要考慮軟體的效能、擴充套件性，模組間的耦合關係，系統的穩定、部署和更新，版本的管理，系統的安全，介面的友好程度。要想簡單，何其之難！
do the ******st thing that could possibly work! 這是xp人士大聲疾呼的口號，我也舉雙手贊成。問題是，我們需要讓簡單的事情，同時又有效。很多人在設計時，並不滿足於實現眼前的功能。看到加法，他們可能還會想到乘法；雖然目前的需求是整數，他們可能想到今後可能會擴充套件到實數，甚至於複數。他們希望能利用某種設計，使其具有更好的擴充套件性。從眼前的需求來看，可能是過度設計；然後對於未來，這個設計才是最完美的方案。
問題不在於設計是否過度，關鍵還是在於設計的理念。是只做目前需要的事，還是未雨綢繆，想好今後的功能擴充套件？這個問題的答案還需要實際的專案開發來檢驗，根據不同的需求，答案會因此而異。
需要設計模式嗎？
重構是必然的！
既然我們無法給出乙個完美的設計方案，因為客戶的需求總是變化的，重構也就成為必然。問題是，這樣沒有新增任何功能的重構，你是否願意為此付出精力、時間去完成。當客戶要求的deadline將要到來的時候，你還認為你的重構工作是必要的嗎？
有時候，軟體設計常常身不由己。然而，純從技術的角度來看，重構非但必然，而且重要。既然我們都明白，複雜的未嘗就是好的，簡單的也不一定是容易的。要保持你的設計盡可能的簡單，可能你還需要時時借助重構的利器，來「改善你既有**的設計」。
對於重構，martin fowler給出了很多條款。這些條款並不是政治課本的教條，也不是「日月神教」的神奇咒語，念著它們就可以防身。這些條款確實很重要，但你需要的是學會他後，然後忘記他，就象張無忌學太極拳那樣。我不是故弄玄虛，事實上只有這樣，重構的精神才能完全融入到你的設計中。
uml重要嗎？
我現在看乙個設計方案的時候，更希望先看看uml圖，然後再看文件的實際描述。如果讓我讀一段**，我希望能先看看類圖，或許更容易理解**的含義。uml在oo世界裡像是世界語，它便於程式設計師間的交流，讓別人更容易理解你的意圖。同時，在設計uml圖的過程中，也是一種對思路的清理，對客戶需求的把握，設計思想的跟蹤。
uml是一種基於物件的統一建模語言，它能夠為系統設計提供清晰直觀的設計。在物件導向世界裡，uml的地位彌足輕重，甚至被稱為是軟體設計的一場革命。對於有計畫的設計，uml的價值就體現得淋漓盡致。如果我們要清晰地表現模組的功能，模組間的關係和系統分布的層次，使用uml可以使設計師減少很多麻煩，同時降低了語義描述的二義性。然而，如果我們在做演進的設計時，uml還有那麼重要嗎？我們只需要對眼前的需求進行編碼、測試，然後重構。可能我們只需要在pair team中討論設計方案，在預定技術框架內**實現的可能和細節。我們完全可以拋開uml繁瑣而死板的設計，畢竟最能忠實體現設計思想的，不是文件，不是用例圖或是什麼類圖，而是**。
那麼，有多少人是這樣想的？
tdd、單元測試和其他
軟體的生命是什麼，是質量！而保證質量的唯一方法，就是測試。傳統的軟體開發過程，強調首先進行需求分析，再從需求分析中抽象出概要設計，進而作出詳細設計，然後編碼，最後才是測試以驗證**的正確性。而測試驅動開發（tdd）改變了編碼的過程，開發僅僅包括三方面的活動：編寫測試用例，編碼並進行測試，重構**以消除重複**使其更簡單、更靈活、更容易理解。通過測試來驅動開發，聽起來是那麼的離經叛道，然而實施起來，又是那麼合理、正確和簡單，前提是：我們不能在一開始就獲得正確的設計！tdd避免了對不完整需求造成的不成熟的設計。通過單元測試，保證了**的正確性與高質量；通過重構，使設計更加簡單、靈活。
EJB中所採用的設計模式
ejb採用多層結構，使用adapter模式和bridge模式將商業邏輯計算和資料庫截然分開。ejb中將對資料庫進行呼叫 如發出select等語句 稱為會話bean sessionbean 而將對應資料庫乙個個記錄的bean稱為實體bean entity bean 由這兩種型別的bean完成對資料庫的...
設計模式四（裝飾模式,採用python 實現）
裝飾模式原理請隨便找書看一下，這裡直接給例子 生產一把刀需要兩個工序，工序一和工序二 process 生產 component 原料 生產刀具的原材料是棒料 bar procedure 生產刀具工序 firstprocedure 工序一 secondprocedure 工序二 from future...
採用邊緣計算的6個理由
採用邊緣計算的6個理由 每種情況都是獨一無二的。然而，可以確定的是，雲計算和邊緣計算之間的平衡可能會推動未來的物聯網架構。為什麼公司應該把邊緣計算作為一種戰略?edge為資訊體系結構引入了自己的複雜性形式，但同時，它有助於為今天的計算環境帶來更大的速度和安全性。這是德勤 deloitte 的話，該報...