打破公有成員函數到大量的私有成員函數

當我寫一個類的公共成員函數，做幾件事情，如..打破公有成員函數到大量的私有成員函數

void Level::RunLogic(...);

在此功能，我發現自己分裂它分爲幾個私有成員函數。有多達分裂公共成員函數成幾個功能，因爲你不會做一兩件事沒有其他沒有意義的，我不希望用戶在什麼樣的順序等。相反，在RunLogic（）函數會擔心什麼看起來像這樣...

void Level::RunLogic(...) { 
DoFirstThing(); 
DoSecondThing(); 
DoThirdThing(); 
}

由於DoThing功能是私人成員功能。在Code Complete中，Steve McConnel建議減少一個類中的函數數量，但我寧願不把所有代碼都放到一個函數中。我認爲他的真正含義是一個類不應該有太多的功能，但我只是想知道其他程序員對此有何看法。另外，我一直在尋求在公共成員函數中暴露越來越少的實現細節，並將大部分工作轉移到小型私有成員函數中。顯然這會產生更多的功能......但這就是問題所在。我用

來源

2009-12-17 Anonymous

一個規則是三個規則。如果我在不同的地方做了三次相同的事情，值得擁有一個單獨的（可能是私有的）成員函數來封裝共享的行爲。

，我一般在這種情況下使用其他唯一的規則是，可讀性。如果我正在查看在IDE中填充多個屏幕的成員函數，我發現很難追蹤所有代碼路徑和可能的錯誤轉向。在這種情況下，將一個整體成員函數分解爲兩個或更多個專用輔助函數是完全合理的。

關於代碼關於類中函數數量的完整評論，請記住函數數量中涉及的最大風險主要與外部可用接口的複雜性有關。您提供給其他人使用的入口點越多，發生錯誤的可能性就越大（例如，由於其中一名公共成員的錯誤，輸入錯誤等）。添加私有成員函數不會增加公共API的複雜性。

來源

2009-12-17 02:15:38

我建議將它們分解爲單獨的方法，其中每個方法負責一個小任務，並且對每個私有方法都有描述。打破方法和方法名稱將使邏輯代碼更具可讀性！比較：

double average(double[] numbers) { 
    double sum = 0; 
    for (double n : numbers) { 
    sum += n; 
    } 
    return sum/numbers.length; 
}

到：

double sum(double[] numbers) { 
    double sum = 0; 
    for (double n : numbers) sum += n; 
    return sum; 
} 

double average(double[] numbers) { 
    return sum(numbers)/numbers.length; 
}

代碼大全地址，每類公開的接口，而不是實現。

將這些較小的方法作爲包保護可能更有意義，因此您可以輕鬆地對它們進行單元測試，而不是僅能夠測試複雜的RunLogic。

來源

2009-12-17 02:16:45 notnoop

其實，我發現你的第一個例子更具可讀性。減少閱讀for循環的努力。我可以管理的連續四個陳述。 – 2009-12-17 12:43:19

你無意中遵循FF規則：

A class should have only one reason to change/Single responsibility principle

這是一件好事。通過恰當地分離責任，確保您的應用不會因爲change

來源

2009-12-17 02:22:56 lemon

而不會輕易中斷。您希望保持公共方法簡單並將其功能分割爲多個私有方法。

麥康奈爾是正確的，你應該減少你保持在一個類的方法數。

這兩個目標並不完全相反。我不認爲麥康奈爾會主張讓你的功能更長，以減少它們的數量。相反，您應該考慮將一些私有方法推入一個或多個可供公共類使用的實用程序類。

完成此操作的最佳方式取決於您的代碼的細節。

來源

2009-12-17 02:23:07 benzado

我同意分割功能。

我一直被教導並一直堅持着一個函數定義爲執行單個封裝的任務，如果它似乎是在做多件事情的知識，那麼就可能重新因素它是可行的。然後是一個類將相似或相關的函數封裝在一起。

拆分這些任務下來，仍然使用在我看來，一個公共成員允許類執行它的目的的方式，重要的任務，同時使其更容易維護。我還經常發現，在同一個複雜方法中有多個類似的代碼段，可以通過參數重新分解爲單個泛型函數 - 這既提高了可讀性，又提高了可維護性;甚至可以減少代碼量。

來源

2009-12-17 02:26:05

我看不出保持特別是公共成員函數儘可能小的優點（在代碼行測量）。通常，長函數的可讀性往往較差，因此在大多數情況下，傳播大函數的實現可以提高可讀性，無論它們是否屬於類的一部分。

至於保持類儘可能小的好建議，這是接口的公共部分和封裝的數據量尤爲重要。原因在於具有大量數據成員和公共函數的類撤銷了數據封裝的優點。

來源

2009-12-17 08:07:57

一個，我用的是沒有人的功能會比滿屏幕空間更多的時間「經驗法則」。儘管頭腦簡單，但它可以幫助您在「一次一屏」的情況下完成所有工作。它也會限制（根據定義）任何一種方法的複雜性。如果您希望將工作交給同事進行進一步維護，升級和錯誤修復（！），保持簡單就很好。考慮到這一點，我同意保持簡單的公共方法幾乎總是正確的選擇。

來源

2010-01-19 13:07:35 TheEruditeTroglodyte

打破公有成員函數到大量的私有成員函數

回答

相關問題