OOP和可伸缩性

我正在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 =数据+行为这一事实，我的问题是:

OOP是否仅对高并发应用不利？
OOP会消亡并被过程编程所取代吗？

因为即使目前如此，许多开发人员仍使用Anemic域模型并在服务中编写逻辑代码。真正的OOP并没有做太多。

最佳答案

答案是，没人知道。编写串行软件的“正确”方法尚无共识，而并行和并行编程则困难得多。

大规模有效并行计算的全部关键是数据的分布，因此有一个论点是，在设计过程中过早地封装数据-或采取对少量任务有意义的数据封装，并天真地希望扩大规模-您正在损害可扩展性。也许这意味着OO在编写可伸缩代码时会被束缚，但是也许这意味着OO与其他所有东西一样，都需要仔细计划才能实现大规模可伸缩性。