2009-04-27 82 views
3

我試圖重構一個緊密耦合的應用程序,並試圖使其更易維護和靈活。如何重構緊密耦合的類?

我有很多單元測試,所以我希望一步一步地重構。

哪個設計&重構模式我應該考慮實現/應用來完成此任務嗎?

我能想到的一些:

而且隨時分享自己的經驗,併爲這種重構工作的最佳實踐。

UPDATE

我執行這個重構because of the reasons explained in this question。基本上我不能在不提取幾個接口的情況下實現一個插件系統,並且這些接口是高度耦合的,這就要求將應用程序分成40多個DLL,以便編譯時無需循環引用問題。

+0

我認爲你可能會找到一本書([在線查看])(http://books.google.co.uk/books?id=9CL446IzhuAC&pg=PA38&lpg=PA38&dq=events+chapter+one+coupling&source=bl&ots= qmJTOuCz90與SIG = EZKvZBjF8QmGohatC97HsmAqG0c&HL = EN&EI = wj6tTqe5LcTX8gON_YyiCw&SA = X&OI = book_result和CT =結果&resnum = 6&VED = 0CEMQ6AEwBQ#v = onepage&q =事件%20chapter%20one%20coupling&F = FALSE)) 「基於事件的編程:服用事件到了極限 」 別拿面值的題目 - 第一章給出了一個有洞察力的描述和方法,以減少/轉移耦合到較少形式的耦合行爲。 – 2011-10-30 12:22:26

回答

0

感謝您的所有答案,在以各種各樣的方式努力奮鬥之後,我發現最好的做法是爲一切創建界面。這使我可以自由地改變設計,並且我只打破一天的構建(一天,因爲項目很大,我需要修復如此多的引用和單元測試+一些重構)。

經過一天提取和修復所有接口,我可以創建單獨的解決方案,並自由地玩設計。

基本上,我認爲應該將所有東西都移動到接口,然後嘗試擺脫內部依賴關係。

8

嚴肅地說,重構不是一件輕率的事情,特別是在緊耦合系統中。在執行它之前,它往往看起來像是一件有價值的工作,但從我的經驗來看,它很快就會成爲一個負擔,因爲它往往更容易引入新的錯誤,而不是解決任何現有的問題。在開始重大重構之前,您應該考慮收益將會是什麼以及有哪些替代方案(如從頭開始創建新產品,僅重構只需要立即使用的部件等)。在開始之前,你一定要對架構,角色和責任有一個很好的理解,以及預期和現有的行爲,以確保你知道什麼時候你破壞了某些東西。

此外,在重構後如何設計它以及如何映射到當前實現以便您可以保持點是有益的。你也應該儘可能經常回歸測試。

當設計很明顯需要重構時,完美主義者可能會感到沮喪,但有時候必須考慮變化的成本/收益並承認戰鬥。如果你必須做出改變,謹慎行事,不要一次性做太多。

+0

@Jeff我在問題中添加了一個更新,說明我爲什麼要這樣做。 – 2009-04-27 17:43:02

+0

說實話,如果有辦法避免它,我打算至少再過兩個月避免它,因爲我在這個應用程序的倉促。不過看起來我必須將類分離才能實現插件系統。 – 2009-04-27 17:44:37

5

重構接口和依賴注入將是減少耦合的關鍵。你可能也想考慮使用工廠創建你的依賴對象。

8

這是一個很大的問題,我們可以寫一本書來回答它。幸運的是,有人已經擁有了。抓住的副本,使用Michael Feathers的傳統代碼有效地工作。這幾乎是一本專門回答你的問題的書。

這也是一本很好的書。我肯定會把它放在那裏與代碼完成,設計模式實用程序員在應該在每個開發人員的圖書館的書目清單。

1

以上所有,然後一些。但是在你開始之前,我會考慮一下大局。定義程序的各個部分(包,項目等),然後制定一個計劃,將功能轉移到適當的包中。然後,一旦所有東西都在邏輯上應該開始使用提取接口,依賴注入和工廠方法來開始解耦程序包。

0

從Phlip一些很好的建議: Refactor the Low-hanging Fruit

我認爲這是很難說哪個具體的重構是在特定情況下不適合大量的詳細信息。