計划效率

Question

我想知道，與任何編程語言中的結構化編程方法相比，采用面向對象的方法來解決問題是否會對程序效率產生影響，特別是在c ++中。

Answer 1

也許。 也許不吧。

您可以編寫有效的面向對象代碼。 您可以編寫效率低下的結構化代碼。

這取決於應用程序，代碼編寫的程度以及代碼的優化程度。 通常，您應該編寫代碼，使其具有良好，干凈，模塊化的體系結構並且設計良好，然后如果您遇到性能問題，則優化導致性能問題的熱點。

使用面向對象的編程，使用它是有意義的，並使用結構化編程，使用它是有意義的。 您不必在一個和另一個之間進行選擇：您可以同時使用兩者。

Answer 2

我記得在20世紀90年代早期，當C ++年輕的時候，有關於此的研究。 如果我沒記錯的話，那些接受（編寫好的）C ++程序並用C語言重新編寫它們的人的速度提高了大約15％。 那些接受C程序並用C ++重新編碼的人，並將C的命令式樣式修改為OO風格（但相同的算法），C ++獲得了相同或更好的性能。 觀察到C語言被轉化為面向對象的風格變得更加有條理，這就解釋了明顯的矛盾。 你在C中所做的事情是因為代碼太多而且做得更好也很容易在C ++中正確完成。

回想一下，我對這個結論感到疑惑。 第二次編寫程序總會產生一個更好的程序，所以它不一定是OO風格的必要條件。 今天的計算機體系結構設計有對OO程序完成的常見操作的硬件支持，並且編譯器在使用指令方面已經變得更好，所以我認為在1992年虛擬函數調用的任何開銷都可能遠遠小於今天。

Answer 3

沒有必要，如果你非常小心避免它。 如果你只是采用最簡單的方法，使用動態分配，虛函數和（特別是）按值傳遞對象，那么肯定會有效率低下。

Answer 4

它不一定是。 算法是最重要的。 我同意封裝將減慢你的速度，但編譯器會在那里進行優化。

Answer 5

如果這是計算機科學論文中的問題，你會說不。

然而，在真實的開發環境中，如果正確使用OOP范例，這往往是正確的。 原因是在實際開發過程中，我們通常需要維護我們的代碼庫，以及OOP范例可以幫助我們的時間。 與C類結構化編程相比，OOP的一個優點是在OOP中更容易使代碼可維護。 當代碼更易於維護時，它意味着更少的bug，更少的時間來修復錯誤，減少實現新功能所需的時間。 最重要的是，我們將有更多時間專注於應用程序的效率。

Answer 6

問題不是技術問題，而是心理問題。 它是通過簡化它來鼓勵你做的事情。

為了做一個世俗的比喻，它就像一張信用卡。 它比寫支票或使用現金更有效率。 如果是這樣，為什么人們會用信用卡遇到這么多麻煩？ 因為它們很容易使用，所以它們會濫用它們 。 不要過度使用好東西需要很大的紀律。

OO濫用的方式是

• 創建太多“抽象層”

• 創建過多的冗余數據結構

• 鼓勵使用通知式代碼，嘗試在冗余數據結構中保持一致性。

最好是最小化數據結構，如果它必須是冗余的，則能夠容忍暫時的不一致。

補充：作為OO鼓勵的事情的例證，這是我在性能調整中有時看到的：有人設置SomeProperty = true; 。 這聽起來很無辜，對吧？ 好吧，它可以波及包含該對象的對象，通常是通過難以追蹤的多態性。 這可能意味着某些列表或字典需要添加到其中或從中刪除。 這可能意味着某些樹或列表控件需要添加或刪除或改組控件。 這可能意味着正在創建或銷毀窗口。 它也可能意味着需要在數據庫中更改某些內容，這可能不是本地的，因此需要執行一些I / O或互斥鎖定。

它真的會變得瘋狂。 但誰在乎？ 這是抽象的 。

Answer 7

可能有：OO方法往往更接近於解耦方法，其中不同的模塊不會在彼此內部進行探索。 它們僅限於公共接口，並且總是存在潛在的成本。 例如，調用getter而不是直接檢查變量; 或者默認調用虛函數，因為對象的類型對於直接調用來說不夠明顯。

也就是說，有幾個因素可以減少這一點作為有用的觀察結果。

1. 編寫良好的結構化程序應具有相同的模塊性（即隱藏實現），因此產生相同的間接成本。 在C中調用函數指針的成本可能與在C ++中調用虛函數的成本非常相似。

2. 現代JIT，甚至在C ++中使用內聯方法，都可以消除間接成本。

3. 成本本身可能相對較小（通常每個指令調用只需幾個簡單的操作）。 這對於在緊密循環中完成實際工作的程序來說是微不足道的。

4. 最后，更加模塊化的風格使程序員可以解決更復雜但更有希望的復雜算法，而不會產生低級錯誤。