面向對象和可伸縮性

我正在閱讀關於爲雲開發可伸縮軟件的ibm.com/developerworks上的文章（現在找不到該文章）。面向對象和可伸縮性

當然，主要想法是無狀態的。沒有什麼應該包含狀態了，這是通過不再有成員數據完成的。每個方法都應該通過傳遞給它的參數來獲得它的日期。

一個例子是這樣的：

class NonScalableCircle { 
    int radius; 

    void setRadius(int radius){ 
     this.radius = radius; 
    } 

    public integer getDiameter() { 
     return 2*radius; 
    } 
}

解釋爲什麼這是不可伸縮的，是因爲你必須首先設置半徑，然後調用的直徑。所以有一個命令來工作，因爲方法使用相同的數據。

可擴展的例子是：

class ScalableCircle { 
    public integer getDiameter(int radius) { 
     return 2*radius; 
    } 
}

當然，這是真的。無狀態的縮放方式更好。考慮到這一點以及OBJECT = data +行爲這一事實，我的問題是：

OOP是否僅適用於高度併發的應用程序？ OOP是否會死亡並被程序編程所取代？

因爲即使現在，許多開發人員都使用貧血域模型並對服務中的邏輯進行編碼。真的沒有太多的OOP。

來源

2011-05-25 Blitzkr1eg

OOP是否會死亡並被程序編程所取代？

不，沒有什麼錯OOP。儘管你可能需要改變一下你如何處理OOP的態度。我還會指出，如果使用功能性而非程序性的範例，寫大規模併發軟件會容易得多。

你的描述無狀態的煩躁而言是Monads

開始與Erlang亂搞看你怎麼大規模的規模，正確的開始。

OOP是不是很適合高度併發的應用程序？

OOP不是問題，命令式語言是。您需要continuation passing和其他功能模式才能夠大規模擴展。函數式編程鼓勵無狀態設計，因此更容易擴展。

但是OOP仍然有它的位置，很多功能語言都是元語言，並且在它們中都有OO。

實現更好縮放的另一種方法是non-blocking IO。

另一個問題是很多企業/業務系統建立在J2EE & .NET的上面，它並不真正鼓勵在「購買更多服務器」之外進行大規模擴展的技術。

如果您想真正利用使代碼正確縮放並高度採取範例切換的優勢。

我還讀取併發性和縮放比例來執行幾百個進程並同時處理幾千個連接。

來源

2011-05-25 18:06:15 Raynos

「不，你不能做程序性和高度併發的。」 WTF？這是無稽之談。現存的絕大多數高度並行軟件都是程序性的，現存的絕大多數高度並行軟件都是程序性的。在原則上，功能以這種方式提供了優勢，因爲人們已經指出了25年，但是說比這更強烈的東西完全脫離了現實。 – 2011-05-25 18:31:06

@JonathonDursi你的權利，聲明太強大了。我調整了它，顯着降低了它。我的意思是以程序的方式做高併發是很困難的。如果是10或1000，它也取決於併發/並行性的級別。 – Raynos 2011-05-25 18:37:45

不夠公平。但是很難以_any_方式進行高級併發:) – 2011-05-25 18:45:23

答案是，沒人知道。對於編寫串行軟件的「正確」方式，目前尚未達成共識，並行和並行編程則更加困難。

大規模高效並行計算的關鍵是數據的分佈，因此有一種觀點認爲，在設計過程中儘早封裝數據 - 或者採用數據封裝對於小型任務數量，天真地希望能夠擴大規模 - 你正在損害可擴展性。也許這意味着面向對象在編寫可伸縮代碼時一手緊隨其後，但也許這意味着面向對象和其他所有事情一樣，需要仔細規劃才能大規模擴展。

來源

2011-05-25 18:44:31

+1「但也許它只是......需要仔細計劃才能大規模擴展。」低估了年度獎;） – 2011-05-25 18:51:06

+1在這個領域缺乏經過驗證的方法。 – Raynos 2011-05-25 18:54:26

儘管您可以通過儘可能地去除狀態來提高本地級別的縮放比例，但只需說出「擺脫狀態」並不能解決太多問題。用戶的期望（並且很大程度上需要）是有狀態的。

高效縮放很少是擺脫狀態的問題 - 這是管理狀態的問題。特別是在分佈式計算的情況下，它主要考慮哪些狀態需要複製到哪些機器上，以便完成特定的工作。

在這方面，面向對象的代碼（如果它至少合理精心設計的）往往是一個很好的事情 - 一個相當明確的對象定義幾乎所有需要被複制的那種狀態對象在該機器上工作。

與流行的觀點相反，函數式編程並不一定是重大改進。首先，FP並沒有消除狀態（根本就沒有）。它確實使國家的各個部分不可改變，但這也不一定有任何重大改進，因爲它可能導致簡單地移除狀態的一部分並用具有相同名稱但具有不同值的「新」替換它。在這種情況下，不可變狀態可以是沒有區別的區別。

如果OO有一個相當大的差別，那就是使狀態足夠明確，以至於設計者（幾乎）被迫考慮給定對象所需的狀態。這往往隱含地鼓勵在很大程度上最大限度地減少該狀態。我還應該提到，在這方面，太多的便利可能是一件壞事 - 例如，無論對象中的狀態數量多少，（例如）爲生成序列化生成代碼都是微不足道的語言使得對於對象包含更多的狀態。當/如果程序員的工作與狀態量成比例（至少部分）時，至少會鼓勵他儘量減少狀態。

在任何情況下，對象都會將狀態分解爲相當小且可識別的塊，這些塊通常很容易管理。除了使並行化和（尤其是）分佈更加困難之外，這實際上使得它更容易，除非代碼僅僅是設計錯誤的真的。當然，沒有任何語言，範式，方法論或其他任何東西都可以防止糟糕的設計，但面向對象設計師提供了一些工具來做好工作，並幫助實現分佈和縮放。

來源

2011-05-25 20:49:33

面向對象和可伸縮性

回答

相關問題