需要關於OOP哲學的建議

我試圖讓C＃中的大型項目開啓輪子。我以前的經驗是在Delphi中，在默認情況下，每個表單都是在應用程序啓動時創建的，並在（gasp）全局變量中形成引用。所以我試圖讓我的思維適應一個100％面向對象的環境，而我的腦袋正在旋轉一點點。需要關於OOP哲學的建議

我的應用程序將有一個大集合的類大多數這些類只會真的需要一個實例。所以我在想：靜態類。我不是很確定爲什麼，但是我在這裏讀到的大部分內容都說如果我的類將持有一個狀態，我認爲這個狀態意味着任何屬性值，那麼我應該使用單例結構。好的。但是有些人因爲逃避我的原因認爲單身人士也是邪惡的。

這些類別都沒有在本程序中的任何地方使用的危險。所以他們當然可以像普通對象一樣正常工作（vs單件或靜態類）

然後存在對象之間交互的問題。我很想創建一個全局類，其中包含許多引用這些類的單個實例的公共靜態屬性。我也考慮過讓他們的屬性（靜態或實例，不知道哪個）MainForm。然後，我會讓每個類都知道MainForm作爲所有者。然後各種對象可以互相引用爲所有者。 對象1，所有者。 對象2等

我擔心電子墨水用完了，或者至少會讓任何人忍耐到足以讓我忍受這麼久的耐心。我希望我已經清楚地解釋了我完全混淆的狀態。我只是尋找一些關於我的情況的最佳實踐的建議。所有的投入都歡迎和讚賞。

由於提前，大衛·詹寧斯

來源

2010-05-19 David Jenings

您可以刪除德爾福形式的全局變量和實例，並根據需要釋放他們。 – TrueWill 2010-05-19 02:49:18

感謝所有花時間回覆的人。你給了我很多想法。多麼偉大的社區。當我說大部分課程只需要一個實例時，我必須承認我誇大了我。事實上，它是大約12中的3個。再次感謝我鼓勵我退後一步，密切關注我的一些班級決策。這個網站將成爲我最重要的C＃智慧源之一，而我正在加快步伐。 – 2010-05-19 12:21:22

你可以試試看看它是如何發展的。考慮在你身邊用NUnit進行開發;如果你這樣做，你會發現你的代碼將保持足夠的靈活性，使架構變化不會太難。

我的首選是避免靜態類和靜態數據，但有時它只是對近期問題有意義。對此，我的建議是考慮實際擁有各種形式的東西。通常情況下，人們似乎希望將主要形式作爲「主要應用程序」，但實際上這種形式可能擁有更好的所有者。

無論如何 - 除了談論和思考可能會發生什麼之外，我會建議繼續前進，嘗試一些選擇並看看他們做了什麼。寫完後不要害怕更改軟件！

來源

2010-05-19 02:33:33

謝謝你。這是我開始的態度。無論我如何處理這些特定問題，我都有信心我可以讓應用程序正常工作。我只想在這個過程中學習一些東西，並且讓應用程序遠離繁雜的垃圾。 :) – 2010-05-19 02:47:24

這是非常正常的程序或其他非OOP語言去思考「每個XYZ一個巨大的靜態類」，這通常意味着你沒有真正想過由於一個類應該代表要被操縱的對象而正在表示的對象。

所以，你需要退後一步，看看DATA和DATA代表什麼。你可能會說：「嗯，它是數據！它代表着數字！」，但你必須抽象出數據代表什麼。數據表示的「事物」是對象。您對數據「事物」所執行的操作將成爲您的方法。

來源

2010-05-19 02:27:02

這個項目實際上是我在Delphi 8年前開發的系統的改寫。從那時起，我一直在維護和改進應用程序，並且我剛剛決定離開Delphi。 Delphi是一種面向對象的語言（主要是）。它只是混合了全球存儲器（大多數面向對象的程序員，毫無疑問，它確實值得稱道）。所以就數據/行爲到類的翻譯而言，我認爲我設置得很好。我在哪裏陷入困境，正在找出離開全球空間的最佳途徑。 – 2010-05-19 02:42:51

單身人士通常是我們通常在設計中看到的許多問題的來源。不過，我認爲創建單例和全局變量是一種將它們作爲代碼異味傳遞給應用程序的手段。

我覺得這會很好地得到SOLID的原理。還有幾個關於這個話題的角度，你應該看和理解。

我推薦的另一本實用書是Kent Beck的實施模式。瞭解面向對象是一回事，在現實世界中實現是另一回事。

查看Windows Presentation Foundation，這是用於構建Windows客戶端應用程序的下一代演示系統。

我想我用足夠的信息轟炸了你，但放鬆一下，一步一個腳印。我覺得你應該在這裏跟蹤幾條曲目，以達到你想要的位置。有一些prototypes微軟提供，你可以學習，然後即興與OOP。

來源

2010-05-19 02:35:29

這個可能會或可能不會有用只是一些隨機的想法：

先從數據不是程序結構。分析數據並找出你在概念上想要表現的東西，然後將其物化。
我的經驗是，在prodedural代碼你在想「我現在在做什麼？」但是使用面向對象的代碼，你正在想「有一天我可能想要做什麼？」
總是會有至少一個主對象，即使它是應用程序對象本身。即使它很誘人，也不要在這個物體上放太多東西。代表數據越多，概念相關對象中的狀態和行爲越容易爲新開發人員學習和維護。
做一個原型。構建一個縮減版本的應用程序，您知道您將丟棄該應用程序，然後在您到達某個點時查看您的代碼，確定哪些對象運行良好，哪些對象沒有運行並重新啓動。

至於整個辛格爾頓的事情 - 不想挑釁 - 忽略naysaysers。有時候Singleton設計模式非常有用，就像有時候EAV數據模型是完美的，MVC是世界上最糟糕的事情一樣。如果您需要放入螺絲，請使用螺絲刀。

來源

2010-05-19 02:43:48 James

在閱讀你的解釋部分時，我認爲如果你有很多你認爲應該是靜態或單身的類，你可能仍然在思考Delphi類型的範例。我不知道我是否遇到過只有大部分物體中的一個的項目。所以我的傾向是你的對象分解可能有缺陷。

真的，你應該開始考慮你在程序中代表什麼。問問自己，如果你有很多隻有一個實例的對象，爲什麼只有一個實例？是否因爲你以一種奇怪的方式保存數據，就像有多個索引匹配的數組一樣。

話雖這麼說，C＃確實有一些好的內置的語義在單身，你不必做無效在您的實例方法檢查

public class SingletonClass{ 
    private static SingletonClass _instance; 

    private SingletonClass(){} 

    public static Instance 
    { 
     get 
     { 
      if(_instance == null){ 
       _instance = new SingletonClass(); 
      } 
     } 
    } 

}

在C＃中可以寫爲：

public class SingletonClass{ 
    private static SingletonClass _instance = new SingletonClass(); 

    private SingletonClass(){} 

    public static Instance 
    { 
     get 
     { 
      return _instance; 
     } 
    } 

}

因此，我建議對使用單身扶着如果你堅持使用模式。單身人士，就像一切都有時間和地點，我不會編寫一個大多數對象都是單身人士的應用程序。

我強烈鼓勵你覺得爲什麼你有靜態方法或單身全局狀態。

來源

2010-05-19 02:56:53

靜態類和單身共享相同的缺點：

緊密耦合到許多其他類
隱藏的依賴關係（很難說其他類使用它們）
測試困難
本質上全球數據
對於單身人士，多重責任（無論他們做什麼+生命週期管理）

在許多解決方案（不是全部！）的情況下是Dependency Injection（DI）的基礎上，Dependency Inversion Principle（即@CodeToGlory提到SOLID原則之一）。這可以手動完成或使用DI Container framework。

馬克塞曼對Dependency Injection in .NET的優秀圖書;我強烈建議。

來源

2010-05-19 03:00:56 TrueWill

需要關於OOP哲學的建議

回答

相關問題