過度使用OOP的症狀和替代方案

最近我失去了對OOP的信任。我已經看到很多關於常見面向對象濫用或僅僅是過度使用的投訴。我不是意味着is-a和has-a relationship之間的共同混淆。我的意思是東西就像ORM在處理關係數據庫時遇到的問題，過度使用C＃繼承，還有幾年在代碼中尋找，並且錯誤地封裝了Scott Meyers 在Effective C++的第23項中提到的錯誤過度使用OOP的症狀和替代方案

我有興趣瞭解更多關於此OOP和非OOP軟件的模式，這些模式可以比其OOP 更好地解決某些問題。我確信，在那裏有很多人提供了很好的建議，如何將這個作爲非純OOP 語言（如C++）的優勢。

有沒有人知道任何好的參考（作者，書籍，文章）得到開始？

請，那我找兩個相關但不同的事情通知：

的OOP概念（如第23項）
模式，其中OOP是不是最好的解決辦法（替代品）通用濫用

來源

2011-01-13 SystematicFrank

過度使用繼承？那是什麼？ – 2011-01-13 22:05:06

使用繼承，最好使用聚合。 – dzendras 2011-01-13 22:09:58

關係數據庫有它自己的問題，這就是爲什麼T-SQL和類似的東西正在發展成爲完整的語言，你可以編寫Java SQL Server程序等等。此外，還有很好的ORM，我寫了自己非常有用的一個。諾亞的評論+1，真的，過度使用繼承？！ – peenut 2011-01-13 22:11:36

那麼我可以推薦你一本書Agile Principles, Patterns, and Practices in C#。當然在C＃中有例子，但這本書的思想是普遍的。它不僅涵蓋了敏捷，還着重於糟糕的實踐，並展示瞭如何將糟糕的代碼轉換爲良好的代碼。它還包含許多設計模式的描述，並演示如何在半實際的薪資應用程序示例中實現它們。

來源

2011-01-13 22:14:08 dzendras

我會說看看遊戲引擎。大多數情況下，面向對象的業績往往會造成業績下滑，而且遊戲行業似乎對消除小幅減速表示迷戀（有時忽略大幅減速）。因此，儘管通常使用支持OOP的語言編寫代碼，但它們的代碼最終只能使用OOP的那些元素，這些元素是乾淨的代碼/易於維護的必需元素，可以平衡性能。

編輯：

話雖如此，我不知道我是否真的會去看看虛幻。爲了使開發者的內容管道更容易，他們做了一些奇怪的事情......它使他們的代碼......好吧，看看你是否真的想知道。

來源

2011-01-13 22:30:28 James

這是必須要做的，但如果你真的想擺脫OOP或至少看看不是面向對象的概念，但使用效果很好：Learn you a Haskell。嘗試一種新的編程模式，然後開始看到可以將大部分概念應用回OOP語言的位置。這解決了你的第二個問題，不是直接的方式，而是相信我，它會比你想象的更有幫助。

來源

2011-01-13 22:37:31 wheaties

你提到C＃有點奇怪。它有很強大的關鍵字，以檢查通常繼承苦難。第一個應該是內部關鍵字。將可見度限制在模塊的概念。這個概念在C++中完全沒有，構建模型不支持它。否則就是一個偉大的概念，「我只相信我的團隊成員才能把它做好」。你當然是。

然後是slammer one，密封關鍵字。非凡的強大，「降壓在這裏停止，不要惹我」。在.NET框架中使用手術精度，我從來沒有發現密封使用不當的情況。在C++中也丟失了，但是使用了模糊的方式來實現它。

但是，是的，WPF對象模型非常沉重。繼承6層深度並使用後門像依賴屬性是冒犯性的。繼承很難，讓我們去購物。

來源

2011-01-13 23:14:14

一種常見的過度使用是在需要一些輸入的程序/腳本中強制OOP，將其轉換爲輸出，然後退出（並且在進程期間不從其他任何地方接收輸入）。程序方式在這些情況下要更清潔。

這樣做的典型例子是在PHP腳本中強制OOP。

來源

2012-10-22 13:02:17 Calmarius

過度使用OOP的症狀和替代方案

回答

相關問題