OOP和可伸缩性

Question

我正在阅读关于为云开发可扩展软件的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 Domain Model并对服务中的逻辑进行编码.真的没有太多的OOP.

Answer 1

OOP 会消亡并被过程编程取代吗？

不，OOP 没有任何问题。不过，您可能需要稍微改变一下处理 OOP 的态度。我还将指出，如果您使用函数式而非过程式范例，那么编写大规模并发软件会变得更加容易。

您所描述的无状态性是Monad的开始

开始尝试Erlang，看看如何正确地进行大规模扩展。

OOP 是否不适合高并发应用程序？

OOP 不是问题，命令式语言才是。您需要连续传递和其他功能模式才能大规模扩展。函数式编程鼓励无状态设计，因此更容易扩展。

但 OOP 仍然占有一席之地，许多函数式语言都是元语言，并且其中包含 OO。

实现更好扩展的另一种方法是非阻塞 IO。

另一个问题是，许多企业/业务系统构建在 J2EE 和 .NET 之上，这并没有真正鼓励“购买更多服务器”之外的大规模扩展技术。

如果您想真正利用使您的代码适当且高度扩展的优势，请进行范式转换。

我还将并发和扩展理解为同时运行数百个进程并处理数千个连接。