一直困擾在按照面向?qū)ο笤O(shè)計總會設(shè)計出一些只有g(shù)et和set方法的對象，那個時候就會想，這樣設(shè)計導(dǎo)致的代碼冗雜問題該怎么解決可是自己又是按照徹頭徹尾的面向?qū)ο笤O(shè)計進行的，后來在看敏捷軟件開發(fā)，原則模式與實踐的時候突然發(fā)現(xiàn)，在最開始設(shè)計的確沒錯，可是設(shè)計的順序出現(xiàn)了錯誤，最應(yīng)該的設(shè)計應(yīng)該是，從最抽象的業(yè)務(wù)流程進行設(shè)計，然后逐漸在這上面添加具體功能，這也就是說，在最開始的設(shè)計的確沒問題，可以為我們提供一個更具體的思路，可不代表這樣的設(shè)計是沒問題的，相反，可能因為在此時并沒有意識到哪些類是多余的，也就是這只是設(shè)計的雛形，我記得，書中說到，作為設(shè)計的最終產(chǎn)品不是UML圖，反而是最后寫出的產(chǎn)品，因為最后的產(chǎn)品才是那個你用面向?qū)ο?，用需求拉動設(shè)計的最后的那個設(shè)計理念。

其實直到看完第六章才發(fā)現(xiàn)tdd原來可以用來剪除冗余設(shè)計，原來可以理清設(shè)計思路，以前一直只是覺得tdd浪費時間，心想著，我設(shè)計都設(shè)計好了，用tdd干嘛，還浪費時間，可是又沒想過，這樣的設(shè)計真的是最簡單，最不多余的嗎？對于細(xì)節(jié)的功能的設(shè)計真的沒有問題嗎？真的可以應(yīng)對變化嗎？

在這次的頭腦實驗里，用以上所說可以非常準(zhǔn)確的設(shè)計出一個產(chǎn)品，快速而保持單一模式的產(chǎn)品。