在C＃程序中使用多個小方法有哪些優缺點？

本質上是什麼標題說。在c＃程序中使用多個小方法有哪些優點和/或缺點？它會減慢速度嗎？它會導致問題嗎？這只是不好的做法嗎？在C＃程序中使用多個小方法有哪些優缺點？

2011-02-23 Tharkis

有多小，我們談論？一般小的好，除非你正在寫的「私人布爾IsBooleanFalse（布爾輸入）{返回輸入;}」 – Massif 2011-02-23 15:08:44

聽起來好像有很多的優勢。我沒有看到任何人提出任何缺點，但。 – Tharkis 2011-02-23 15:19:48

這是因爲您在使用多種方法時所接受的折衷與僅在極端情況下才考慮的益處相比是微不足道的。 – 2011-02-23 15:26:27

這個問題是很模糊的，但這裏是我的總體思路：

更多的方法將不會減慢您的應用程序的任何顯着的程度。這是在非常小的水平上進行優化，不值得花時間。

較小的方法更容易閱讀和攝取。他們也更可能只有一項責任。這兩件事都很好。

很多方法可以迫使讀者保持較大的「心理堆棧」，因爲他們通過閱讀代碼，並有跟蹤大量的方法調用的。只要方法只做一件事，而且命名得很好，這通常不是問題。

這真的取決於你的情況，你寫，等等。但總的來說，我的經驗法則是幾個小方法比一個大，整體的方法更好的東西。

2011-02-23 14:53:42

在分鐘級別？我猜的應用程序正在:) – Stormenet 2011-02-23 15:00:23

@Stormenet之前運行了數年：[看這裏，向下滾動到「minute²」 - 這是明顯的，如「我的蠑螈」的一個（http://dictionary.reference.com/瀏覽/分鐘） – Timwi 2011-02-23 15:10:53

@Timwi哦，我看到的，有趣的感謝:) – Stormenet 2011-02-27 15:21:36

這實際上是一種很好的做法，因爲你的方法有一個明確的功能，只做一件事。

2011-02-23 14:53:28

一般而言，較小的方法更可取，而不是更大。但是你不需要爲每一個可能的邏輯步驟制定一個單獨的功能，太多的單線也是不好的。一個好的方法應該適合一個或兩個屏幕。還有一件事：試着遵循邏輯，而不是表現。只有在遇到真正的性能問題時，才應合併（或拆分）函數，否則分解應遵循您的邏輯。

2011-02-23 14:54:30 vissi

如果你的意思分手會是什麼代碼大塊成多個更小的方法，我會說，它實際上是很好的做法。

它有助於使你的代碼可重用在某些情況下，這也意味着代碼更易於管理，更容易在未來的更新。

例如，如果你有一個方法，會做這樣的事情：連接到數據庫執行查詢過程對結果

打破了成多個更小的方法的一些計算意味着你可以重用數據庫連接代碼，查詢的執行將保持獨立，您也可以重新使用代碼進行計算。

2011-02-23 14:56:17 Purplegoldfish

用多種方法分隔代碼可讓您重用它們。它也使你的代碼更加有組織。

調用的方法並不需要很多資源的，所以你不應該擔心性能問題，除非你對例如非常明智的，低資源的嵌入式系統開發。

通常認爲每個邏輯責任都有一個方法是很好的做法。

2011-02-23 14:56:43

這是一個非常開放的問題，在某些程序中，它在其他程序中是好事，這將是不好的。

你應該記住保持兩個原則是

DRY - 不要重複自己

KISS - 保持簡單愚蠢。

通常，每個方法應該包含一個分立件的功能和僅該功能，但是，如果該選項沒有給它在一般的形式，它應採取而不是具有兩個方法來完成類似的任務。

應當指出的是，沒有道德訓練的軟件工程師將永遠同意寫一個 DestroyBaghdad程序。基本的職業道德，而不是要求他寫一個DestroyCity 程序，對此巴格達可以作爲參數。〜納撒尼爾·S. 鮑仁斯坦

至於效率，編譯器不會介意你寫哪一種方式，良好的編碼風格是誰編寫和維護它的人的利益。

2011-02-23 15:01:36 Robb

我知道這是一個開放式的問題。這是有意這樣的。但是，這聽起來像這樣編寫代碼沒有真正的缺點？ – Tharkis 2011-02-23 15:18:34

回答