面向对象和可伸缩性

我正在阅读关于为云开发可伸缩软件的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

面向对象和可伸缩性

回答

相关问题