为灵活性和健壮性而设计:异步消息模型、OOP和函数式编程

“吩咐,不要询问”:按照Pragmatic Programmers的说法,在面向对象编程中最好“吩咐一个对象让它去做些什么,而不是向它索要数据”。Michael Feathers认为“这是一个极佳的建议”,特别是对于比较大的系统:

\u0026#xD;

返回值把工作又推回给调用者。单单做完一件事然后向协作者发送一条消息还不算完;你必须等着看有没有什么被送回来,然后可能还要做更多的事情。如果不返回值会让我们更轻松一点。

\u0026#xD;

Feathers认为在测试驱动开发中使用Mocks会导致这种类型的架构:

\u0026#xD;

与其吩咐一个对象去做事,然后询问它是否已经完成,你不如吩咐它去做事,然后看看它的协作者有什么变化。[……]这有点像工作流。[……]遇到新需求的时候比较不会影响到设计。而且,这样很合理。每个对象负责一件事情,并且通知下一个接班的对象。

\u0026#xD;

我们还可以更进一步。Feathers主张如果没有返回值需要等候,那么发送“异步消息比同步消息更好“。实际上H.S. Lahman早就主张过在面向对象架构中的“行为是被假定为异步的”。如今的OOP模型是同步的,这是因为在面向对象编程语言中“没有区分开消息和方法”。因此“更加难以构造出正确的OOA/D模型”,正确的模型不仅可以显著提高可维护性,还包括健壮性。

\u0026#xD;

Michael Feathers描述说这种做法也与Erlang的模型相吻合:

\u0026#xD;

Erlang隐含的思想是,如果你能创建大量的进程,并保证它们绝不共享状态,你就可以开发出更加健壮的系统。每个进程接收消息,做自己的工作,然后向其他进程发送消息。消息的发送主要是异步的。

\u0026#xD;

Feathers认为,“吩咐,不要询问”的编程模型“几乎是函数式编程的反面”,虽然“两者都有一个相对无状态的河床让数据从上流过”:

\u0026#xD;

在最纯粹的函数式编程中,你从不吩咐,总是询问。而且如果有缓求值(lazy evaluation)帮忙,系统只需完成最必不可少的操作来回答你的问题。

\u0026#xD;

不过可争议的是Erlang不能被认为是纯粹的函数式语言。Feathers也特别引用Ralph Johnson的观点,他指出Erlang的“核心里头是OO”。

\u0026#xD;

就你的观点,哪种无状态模型最适合处理现今的适应性和健壮性问题呢?是Erlang的异步消息模型还是某种纯粹的函数式编程方法(如Haskell)?

\u0026#xD;查看英文原文:Designing for flexibility and robustness: Asynchronous message model, OOP and Functional Programming

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

2名名名名名名名名名名名名名名名名名名名

谢谢啊011702

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值