如何/何時在OOP中編寫可重用方法

Question

我經常發現自己處於一種情況，即在一個方法中多次重複兩三行代碼，然後考慮是否應該用單獨的方法來避免代碼重複。但是當我將這些行移出該方法時，我發現剛剛創建的方法不可重用，僅使用了一次或需要重載才能用於其他方法。

我的問題是我們應該尋找什麼樣的模式，這表明我們應該創建一個新的方法。我感謝你的迴應。

Answer 1

作爲一般規則，請始終將這些情況視爲功能實體。如果一段代碼在功能上執行任務（複雜的字符串轉換，解析等），則應該編寫可重用的方法。 如果該功能特定於某種類型，則編寫一個extension method。

Answer 2

您可以在Action<>或Func<>類型的函數中創建局部變量，並將代碼片段分配給它。然後，您可以在函數內部的任何地方使用它，而不會用太多的小幫助函數污染您的類。

Answer 3

如果您打算移動到另一個方法的代碼行執行特定的一組操作（如讀取文件，計算值等），那麼最好重構爲另一個輔助方法。同樣，只有在代碼中的幾個地方調用助手方法，或者調用方法太長（定義too long取決於開發人員）時才執行此操作。

類似問題

• How do programmers practice code reuse
• What techniques do you use to maximise code reuse?
• Code Reusability: Is it worth it?
• Coding Priorities: Performance, Maintainability, Reusability?

Answer 4

我會念叨DRY原則開始（不要重複此致小精靈），希望它會給你一個很好的回答你的問題，這是一個問題，所有的開發者應該問自己的方式，很好的問題！

見Don't repeat yourself

我想離開它幹，因爲它是這樣一個簡單但功能強大的概念，這將需要一些閱讀和大量的實踐中得到很好的補充。但讓我試着直接回答你的問題（恕我直言），

如果你不能給你的方法一個反映你的方法正在做什麼的名字，把它分解成有意義的片斷。

你會發現自己乾脆你的代碼，可重用的作品會顯示出來，你可能永遠不會發現自己重複代碼。

我會這樣做，即使它意味着只有幾行代碼的方法。

按照這種做法會給意義的代碼，使其可讀和預見，肯定更可重複使用的

Answer 5

不要把過多的功能在一個方法/類。嘗試按照single responsibility principle。這需要一段時間才能熟悉這種方法。但是一旦你達到這個水平，你會注意到它是由它自己完成的。在編碼之前，試着問自己，你的概念包含哪些功能單元。

例如，你想開發一個應用程序，它可以索引PDF文件的內容。這只是虛構的，但第一眼，我可以找出至少有三個組成部分：

1. PdfParser - 此爲您提供了一個PDF
2. 索引的內容 - 從解析器和計數意味深長的話得到輸入
3. 存儲庫 - 它是爲了持久性;這可以是通用的;所以只要說repository.Get<IndexData>(filename)什麼的

你也應該嘗試對接口進行編碼。特別是當涉及某種UI時。例如，您正在開發與WinForms聊天客戶端。如果遵循MVC/MVVM-模式，則可以輕鬆（即比對Form對象編碼更容易）將原始邏輯與WPF版本的客戶端一起使用。

Answer 6

如果您構建可重用性的方法，但不要在多個地方使用它，那麼您的方法的可重用性並未得到真正的驗證。 提取有意義的方法，並在實際有機會重用代碼時重新設計這些方法的可重用性。