寫一段文字描述程序要完成什麽樣的功能，然後將這段文字的名詞轉換成類或者類的屬性，將動詞轉換成類的方法。這是80年代中期的經典做法。

<<設計模式解析>> 2nd 開篇就說，上述方式有局限性，因為只關註了如何實現對象，是不完整的解決方案。或許只應該是解決方案中的一部分。

我目前的做法是，仍然用一段文字來描述程序要完成什麽樣的功能，根據自己的經驗（當然也包括名詞和動詞分析法）寫出調用代碼，然後再慢慢實現每個類。我這個方法有個出處，源自於Bob的敏捷軟件開山之作裏面描述的測試驅動編程。他的原意是寫一個Unit test，然後慢慢的實現所有的類和方法，最終讓Unit test通過。但是很多時候，Unit test並不那麽容易建立，畫UML裏面的時序圖感覺代價比較高，我更願意通過代碼來講述故事大綱，就像寫作文先寫提綱一樣。

舉個例子：用戶登錄網站，如果用戶名、密碼、驗證碼都正確，可以登錄。在這個後臺驗證程序邏輯裏面，我用如下代碼將故事大綱先寫好：

User user = UserManager.login(id,password,authenKey);

if(user!=null){

log.info("User logs into web site successfully");

}

然後實現細節在UserManager類裏面逐層展開，要做如下工作:

1)檢查驗證碼

2)通過SHA256算法，計算密碼是否正確

3)如果驗證通過，創建User對象，裏面包含了用戶信息，並返回

4)錯誤處理，如果驗證失敗，則拋出異常告知哪種錯誤，錯誤可能有幾種，比如驗證碼錯誤，用戶名或者密碼不正確。

由於有錯誤處理，所以調用代碼修改為：

try{

User user = UserManager.login(id,password,authenKey);

log.info("User logs into web site successfully");

//do something for correct user

}catch(LoginException ex){

log.error(ex.getMessage(),ex);

//do something for wrong authentication

}

然後就開始實現User,UserManager,LoginException類。可能還需要一個類來處理驗證碼,一個類來處理SHA256算法。

在設計類的時候，盡量遵守單一職責原則，組合優於繼承原則等等。後面會繼續談到。

我自己概括我的方式為：需求驅動編寫自頂向下的代碼。這種方式的優點是細節將被逐層展開，容易把握大方向，避免一上來被細節牽著走，寫出復雜而難以維護的代碼。而且避免了繪制UML圖帶來的高成本，慢進度。用程序來講故事，是非常自然的事情。不過這種方式必須結合不斷的重構，可能由於特殊的需求引入一些算法和模式，改變了故事大綱。一個程序的代碼，就像一個生命體，是不斷演化，甚至積累到一定程度和初始面貌截然不同。

再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://blog.csdn.net/jiangjunshow

最佳程序設計探索之一 需求驅動編寫自頂向下的代碼