在平時的開發中，我們總是習慣於使用過程化的思維方式來編寫**，沒有通過開發高內聚的方法，來結構化自己的思維，從而消除邏輯重複，邏輯復用不僅僅是指在乙個平面內的邏輯復用，更應該是一種結構化的邏輯復用。下面，我用平時開發過程中乙個重構的過程，來做乙個描述。
假設，現在有三個類，如下圖所示：
在這三個class中，分別有三個重複的屬性：a, b, c, 而且這三個屬性具有相關性，對應於乙個功能的具體實現，
在功能處理類functionhandler類中，對這個功能的具體實現做處理，如下圖：
引數的型別是 abc,而不是a或b或c。利用繼承或者多型，結構化地消除重複邏輯並復用。開發高內聚的方法，我個人認為對於消除重複邏輯，是很重要的。而高內聚的方法，肯定是存在於乙個結構中的。應盡量避免使用過程化的思維習慣來開發軟體，使用結構化的物件導向的方式來思考。消除重複的邏輯，獲得變化空間！
最後，我認為是《測試驅動開發》,《卓有成效的程式設計師》給我了這樣的啟發,感謝kent beck!
大小: 6.2 kb
大小: 11.1 kb
大小: 10.8 kb
重構優化的思考
重構的時機 什麼時候重構？重構絕非沒事的時候改動下 讓 更美觀，這個意義真的不大，太浪費精力了。當發現以前書寫的 不滿足目前的功能需求時，那麼可以考慮重構 當以前的 不滿足目前的效能要求時，需要重構 甚至於重寫，重寫要慎重 當可預見的未來裡，可能會出現功能效能瓶頸時，需要重構。總而言之，沒有明確的有...
關於重構的思考
目前組內專案的 數量已經到了1.7w行了，架構或者說設計已經逐漸顯示出了疲態，有些功能我們已經超出了我們之前的設計範圍。我們當前的困境，我們在新增部分新功能的時候已經開始強行相容，用一些很變扭的操作實現。同時也已經埋下了很多坑。我們應該進行重構的操作，把當前看到的問題整理調並整我們的設計。這週我進行...
對於重構的思考
最近接到乙個任務，大致就是在一段 裡多加乙個else if 來做些事情。考慮到後面有可能還會加條件，想重構部分 弄成策略的。做了大半後發現業務邏輯比我想象的要複雜，按這個思路重構完可能會出現意外的bug，或者重構失敗。於是我打算還是加else if來解決。這件事情的教訓就是 在非常了解一段邏輯之後再...