博客专区 > LinkerLin的博客 > 博客详情
基于 CSP 的设计思想和 OOP 设计思想的异同
LinkerLin 发表于1周前
基于 CSP 的设计思想和 OOP 设计思想的异同
  • 发表于 1周前
  • 阅读 1828
  • 收藏 56
  • 点赞 3
  • 评论 7

1小时搭建人工智能应用 让技术更容易入门>>>   

Go语言推崇的CSP编程模型和设计思想,并没有引起很多Go开发者包括Go标准库作者的重视。标准库的很多设计保留了很浓的OOP的味道。本篇Blog想比较下从设计的角度看,CSP和OOP到底有什么区别。

下面,我们来看一个例子,如果我们有一个项目,需要做一个TCP连接中继器(请原谅我的用词)。我们先按照OOP来设计下:

  1. 系统的结构:需要有一个客户端和一个服务器端。分两个进程分别跑在不同机器上。
  2. 系统对象关系拆分(这里有所简化,E-R图等省略):连接中继器类--系统的主类config类--描述配置的类、connection类--每个连接一个conn类的实例、pipe类--提供一个管道,把上游的连接和下游的连接打通,把数据从A--pipe--B、encrypt工具类,提供各种加解密工具。
  3. 理清楚系统中各种对象(类)的作用关系,设计接口的细节。这里的接口,其实就是对象之间相互发送的同步阻塞的消息。
  4. 设计错误处理,日志等。
  5. 从性能方面审视整个设计,优化。

=====

好,我们再按CSP的思路来设计下,是这么一个过程:

  1. 我们需要一个 main 协程来处理各种命令行参数的配置,收集处理配置文件; 如果是server,那么初始化server的主协程 -- tcpRemote;如果是client,则启动client的主协程 -- tcpLocal;
  2. 分别设计 tcpRemote和tcpLocal。tcpRemote 是server主协程,负责在指定的端口监听,如果有新的连接连入,则启动一个协程处理 -- serverConn ; tcpLocal是client的主协程,负责在客户机的指定端口监听,如果有连入连接,则启动一个协程处理 -- clientConn;
  3. 分别设计 serverConn和clientConn。serverConn 处理新连入连接的请求,把连接交给shadow函数处理得到一个装饰后的连接,析出目的Addr,发起连接到远端,再交给 relay 函数处理。clientConn 处理新连入的连接请求,析出目的地址, 发起一个新的到server的连接,把连接交给shadow函数处理得到一个装饰后的连接,转发请求给server,接下来的工作交给 relay 函数来处理。
  4. shadow函数,接受一个连接返回一个连接,标准的装饰器。由于需要实现多种加密算法,所以shadow函数有很多实现。程序启动时,在初始化阶段根据配置,注册好对应的shadow函数实现。
  5. relay函数,一个桥接器,接受两个连接,异步转发两个连接中 上行 和 下行 的数据。分别用两个协程来实现数据的 上行 和 下行 的转发逻辑。
  6. 设计错误处理,日志等。
  7. 从性能方面审视整个设计,优化。

=====

OOP部分写的比较简略,但是设计思路还是能看出来的,OOP的设计 核心的围绕点是系统中的对象的种类、职责以及相互的关系;OOP在低并发的时代诞生,对于系统中动力分配是不怎么重视的。在遇到具有共性的点的时候,OOP多是用接口的形式表达,多个不同类实现同一个接口。

CSP的设计 核心的围绕点,是系统中的动力源,也就是系统中动力的来源。动力源在Go语言里就是goroutine;由于goroutine往往是通过闭包函数创建出来,所以闭包函数捕获的upvalue等,也就成了父goroutine和子goroutine之间的一种隐藏的协议。更重要的,每个协程,本质上就是在调度发生时,自动把 上下文 保存起来的回调函数。这大大简化了状态的维护工作。在遇到具有共性的点的时候,CSP是多用装饰器和桥接器,把系统中的共性用函数的参数表达出来。

这两种设计中,接口和函数其实可以相互转换,一个接口只有一个方法的等价于一个函数;而几个函数构成了固定的组合,在Go里面等价于实现了某个接口。所以,这种对共性抽象的方法并没有太大的差别,甚至有人就推崇在Java中,一个接口就只有一个方法。

=====

OOP、FP、CSP、Actor等思想,其实都是在做取舍,究竟要隐藏那些细节暴露那些功能。如果什么都不考虑,那就是汇编了(近似的说法)。没有最优的设计思想只有合适的设计思想。

无论OOP/FP/CSP/Actor模型,都是可以相互转换、替换和实现。

FP/CSP/Actor中大量用闭包,其实就是把OOP的结构体交给编译器去自动生成而已,每个闭包函数捕获的upvalues在各种支持闭包的语言中,多是交给编译生成一个特殊命名的结构体,并在闭包传递时一并生成实例并传递引用。这样就使得一些地方用于消息传递的结构体可以省略,很多时候在chan中传递一个func()比传递一个消息更加的方便。Go的chan可以看作是把传统OOP语言以 方法调用形式 表达的同步阻塞消息传递,改成了显式的消息传递,更好的是,多路分发和逆多路分发机制也集成在语言中。

OOP中的方法调用本质上就是一种同步阻塞的消息传递,这点在ObjC中表现的非常清楚,ObjC中每个方法调用本质上就是发送了一条消息给某对象(sendmsg是一个变参数函数)。OOP隐形约定了,所有的进程内的语言运行时级别的消息传递都是同步阻塞的。而Go/Erlang等CSP/Actor模型的语言,打破了这一点,提供了语言级别的异步非阻塞的消息传递。

如果我们把软件设计分成 装配、动力驱动、可变性 三个方面考虑。

OOP的装配工作量比CSP要大的多。每个接口的每个方法都可以看成是一个螺丝,只有你紧固了每一个螺丝,OOP设计的软件才可以运行。而CSP设计的程序,每一个协程的创建,都是一个装配点,仰赖方便的闭包机制,装配所需螺丝是一次性自动紧固的。这就是CSP在设计上的优势之一吧。

在动力驱动方面,OOP由于假设了方法调用是同步阻塞的消息传递,其动力驱动也比较原始,大部分是依赖操作系统提供的线程和进程机制。但是CSP则提供了异步的非阻塞消息机制,以及自动上下文保存的可中断函数(也就是协程)。这些机制使得CSP的动力驱动简单高效。

在可变性方面,OOP的合约是由接口和结构体来约束的,而CSP的合约是由函数签名和闭包的upvalues来约束的。函数的参数和返回值可以都是空,只用upvalues来隐式表达约束。因此CSP在可变性方面也是更优秀的。

 

P.S.

需要强调的是OOP并没有什么特别的不好的,相反OOP具有巨大的优势,就是容易设计。

CSP虽然会要求从设计上改变即有思路,耗费较多的脑力,但其设计方案简单容易扩展,具有巨大的优势。

标签: CSP Go Actor 设计
共有 人打赏支持
LinkerLin
粉丝 60
博文 49
码字总数 8963
作品 1
评论 (7)
__JM_Joy__
Show me the code.
ddatsh

引用来自“__JM_Joy__”的评论

Show me the code.
+1
qgymje
在Go里,可以将CSP的概念融入到OOP中,最为简单的做法是将函数调用的参数与返回值的类型都改为channel,这样可以做到function call在一定程度(channel没满)上为异步,至于闭包context不是重点,这个概念在Actor Model里表示为state; OOP思想可以体现在实现Actor Model的语言里,CSP是一种特殊的Actor,关注点不同
LinkerLin

引用来自“qgymje”的评论

在Go里,可以将CSP的概念融入到OOP中,最为简单的做法是将函数调用的参数与返回值的类型都改为channel,这样可以做到function call在一定程度(channel没满)上为异步,至于闭包context不是重点,这个概念在Actor Model里表示为state; OOP思想可以体现在实现Actor Model的语言里,CSP是一种特殊的Actor,关注点不同
嗯,这么理解是可以的。
我说的是设计上,可以不用先考虑chan的使用,只关注goroutine,设计好goroutine后,goroutine之间的通讯可以不用chan,而是用闭包捕获的upvalues来沟通。这样就省去了通讯数据结构的设计。或者在chan中传输func,也一样省去了通讯用数据结构。
qgymje

引用来自“qgymje”的评论

在Go里,可以将CSP的概念融入到OOP中,最为简单的做法是将函数调用的参数与返回值的类型都改为channel,这样可以做到function call在一定程度(channel没满)上为异步,至于闭包context不是重点,这个概念在Actor Model里表示为state; OOP思想可以体现在实现Actor Model的语言里,CSP是一种特殊的Actor,关注点不同

引用来自“LinkerLin”的评论

嗯,这么理解是可以的。
我说的是设计上,可以不用先考虑chan的使用,只关注goroutine,设计好goroutine后,goroutine之间的通讯可以不用chan,而是用闭包捕获的upvalues来沟通。这样就省去了通讯数据结构的设计。或者在chan中传输func,也一样省去了通讯用数据结构。
无论OOP,CSP, Actor, 它们的关注点都是message passing,oop目前大多表现为同步,actor为异步,csp半同步半异步
qgymje
ps: 只是简单的概括,要说细节的话,太多说不完:laughing:
LinkerLin

引用来自“qgymje”的评论

引用来自“qgymje”的评论

在Go里,可以将CSP的概念融入到OOP中,最为简单的做法是将函数调用的参数与返回值的类型都改为channel,这样可以做到function call在一定程度(channel没满)上为异步,至于闭包context不是重点,这个概念在Actor Model里表示为state; OOP思想可以体现在实现Actor Model的语言里,CSP是一种特殊的Actor,关注点不同

引用来自“LinkerLin”的评论

嗯,这么理解是可以的。
我说的是设计上,可以不用先考虑chan的使用,只关注goroutine,设计好goroutine后,goroutine之间的通讯可以不用chan,而是用闭包捕获的upvalues来沟通。这样就省去了通讯数据结构的设计。或者在chan中传输func,也一样省去了通讯用数据结构。
无论OOP,CSP, Actor, 它们的关注点都是message passing,oop目前大多表现为同步,actor为异步,csp半同步半异步

回复@qgymje : CSP也是异步的啊。
×
LinkerLin
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
* 金额(元)
¥1 ¥5 ¥10 ¥20 其他金额
打赏人
留言
* 支付类型
微信扫码支付
打赏金额:
已支付成功
打赏金额: