OOP - 我是否過於複雜？

我正在看我的一些項目，並將它們與我在github上看到的東西進行比較，我覺得我過度思考。我喜歡OOP，但我覺得我製作的文件太多，班級太多。OOP - 我是否過於複雜？

例如，在一個小型項目中，我有一個跳棋遊戲，我有很多文件可能都會進入一個文件/類。我怎麼知道我什麼時候想過我的解決方案？這是我的一些文件的樣子;

|src 
| |- player.cpp 
| |- piece.cpp 
| |- color.cpp 
| |- ...

當然，還有更多的文件會處理像規則，設置遊戲，GUI等東西。但在這個簡短的例子中，你可以看到我的項目如何能夠變得非常大。這是常見的，用這種方式寫東西？或者，我應該簡單地寫一個player.cpp文件，其中包含多個類，在這種情況下，這些類是相關的並且會設置件/顏色/特徵信息等。

來源

2017-10-22 Daniel Contreras

看起來像這屬於[軟件工程]（https://softwareengineering.stackexchange.com/） – gman

最後，它是（主要）你必須處理你的代碼庫 - 所以要留意任何你的代碼導致你痛苦的方面。當你注意到你花了很多時間來維護某些東西，或者你的代碼庫的一個特定方面正在給你帶來麻煩時，花點時間思考它爲什麼會給你帶來麻煩，以及如何改變你的方法來減少或者消除問題。然後嘗試新方法，看看它是否有幫助;如果確實如此，則將其作爲新的「最佳做法」;如果沒有，拋出它並尋找其他東西。重複，直到你快樂:) –

^^在上述過程結束時，你不僅會知道什麼方法對你有用*（與其他人可能與你的想法不同），但你也會很好地理解你爲什麼要按照你的方式來做事情，而不是以其他方式做事 - 因爲你以另一種方式嘗試了它，並且不喜歡它。 –

-1

每班應設計和編程來完成一個，只有一個，事情因爲每個類被設計成只有一個責任，許多類用於構建一個完整的應用程序

來源

2017-10-22 05:09:58 Rmanshk

是，分發您代碼到多個文件是一個很好的做法，因爲它使您的項目可維護。

我可以看到你對一個小項目的擔憂（值得嗎？），但是在真正的大項目中，如果你不這樣做，最終會讓人們在一個大文件中永遠滾動，並通過搜索文件找出他們正在尋找什麼。

儘量保持文件緊湊，並且每個文件一個類，每個類都強健且目標明確。

有時，我們寫函數文件。對於每一個小內聯函數都有一個文件是不明智的，它會無故增加文件的數量。在文件中有一系列功能會更好（例如與打印相關的功能）。

最後，它可能是基於意見的，它是文件大小和文件數量之間的理想平衡點，但我希望自己清楚。

來源

2017-10-22 05:10:06 gsamaras

太過分了，我認爲你應該用它來分隔OOP文件的方法是一種單一責任範式。每個班級都應該在您的問題空間中完全代表一件事情。所以你應該絕對有一個類（通常是afile），用於'player'和一個類'piece'等。這與單個責任範式類似，每個函數代表單一行爲。總之，類是名詞，因爲功能是動詞。 – Spaceman1701

實際上，您提出了兩個截然不同的問題：「什麼是分離功能到類的良好粒度」和「什麼是組織項目文件結構的良好實踐」。兩者都相當廣泛。

第一個答案可能會遵循單一責任成語。第二個答案是讓文件夾結構類似於命名空間結構（例如在boost中）。將當前存儲在src文件夾中的所有方法都不適用於C++，因爲它會導致較長的文件名，以防止在具有相同名稱的類出現在不同名稱空間中時名稱衝突。較大的項目確實傾向於擁有太多的文件，因爲一個類需要4-5個文件。這就導致了爲項目選擇適當粒度的另一個問題......

來源

2017-10-22 08:14:06 VTT

人們往往擔心「太多班級」或「太多文件」，但這在很大程度上是歷史遺留問題。 40年前，當我們在穿孔卡上編寫程序時，必須攜帶大型托盤和其中的一些盒子（並且不要扔掉它們！），這肯定會成爲一個問題。 35年前，當你能夠獲得PC的最大硬盤是33MB時，這是一個問題。今天，如果您不考慮購買SSD小於512GB的PC，並且可以訪問TB級和PB級的在線存儲，那麼程序佔用的文件數量和字節數對開發流程來說基本上是無關緊要的。

這對我們人類意味着什麼，我們應該利用這種豐富的能力來改善我們代碼的其他方面。如果更多文件可幫助您更好地理解代碼，請使用更多文件。如果更長的文件名可以幫助您更好地理解代碼，請使用更長的文件名。如果遵循像「每個類一個.cpp和一個.h文件」這樣的規則可以幫助人們維護代碼庫，那麼遵循規則。關鍵是要關注真正重要的問題，例如「是什麼讓代碼更易於維護，更易讀，更容易理解我和我的團隊？」

解決此問題的另一種方法是詢問「文件數」是否是確定代碼是否可維護的有用指標？雖然這個數字顯然對應用程序來說太低了，但我不能告訴你10或100或1000是否是合適的數字（至少不知道它們包含的類的數量）。因此，它似乎不是一個有用的指標。

這是否意味着一個程序應該有1000個文件全部堆積到一個文件夾中，全部編譯並鏈接到單個庫或可執行文件中？這取決於，但似乎在同一個命名空間中的1000個類會有點擁擠，並且由此產生的程序可能太單一。在某些時候，您可能會想要將架構重構爲更小，更有凝聚力的包，每個包都有適當的責任區。當然，沒有人能告訴你這個幻數是什麼，因爲它完全取決於應用程序。但是，這不是驅動這種決定的文件數量，而是這些文件應該在邏輯或體系結構上相互關聯。

來源

2017-10-24 02:22:58

OOP - 我是否過於複雜？

回答

相關問題