在服务端写业务的时候, 面向对象和面向过程到底哪个更好?

[petelin]

抛砖引玉说一下: 我认为面向对象完全是因为 GUI 或者有状态 /强逻辑的代码需要

从 gui 上讲, 我们把人物抽象成一个对象,内部保存状态, 然后每一个方法都会改内部状态,这个非常合理,非常自然.因为每一个方法都强依赖人物的状态.

同理设计中间件, 数据库的时候也是需要的.

问题是在写业务的时候, 本来就非常简单的东西, 从 A,B,C 拿出来东西处理一遍发给 D,然后整理一下返回. 就这么一个东西, 强行面向对象的结果就是, 把本来非常简单的的中间状态放在了对象里, 这样后面维护的人面对的是一个混沌的系统. 结果就是你想要了解一个业务就要全部通读一遍. 改代码小心翼翼.加代码也是, 你要在混沌的系统里,摸清楚你处理的时候系统是什么状态.

如果是用纯函数式变成, input->output 没有中间变量, 那我随意一个函数我知道我只会影响 output 的输出. 加代码也清楚.

不过面向函数写起来参数很容易满天飞,也不是很完美.

不知道大家怎么看.

ps: 我举个例子 比方说我们有一个请求里面有 lat, long. 但是是字符串, 第一步肯定要解析成 float64

面向函数 lat, long := parseLatLong(...) // 这行之下你就知道 lat,long 一定可用,(贾如后面有修改一定是在同级函数里)

面向对象 handler.parseLatLong() ... ... 你来维护老代码, 你想看见 lat,long 在对象里, 你想用但是你要找什么地方初始化的, 后来有没有被修改(肯定不在同级函数, 而在另外一个方法里,甚至可能有三四层调用).

[petelin]

其实是因为最近有一个接口写的长了, 只能用分模块处理一下, 但是本来很浅显的数据处理(不过就是拿数据, 洗数据,patch default 值, 计算一下在加几个字段) 被强行分割成几个模块, 看起来是清晰了,但其实真没有写 300 行面条代码读起来块...

如果用面向过程的方式, 我可能不需要理解业务, 但是我能阅读的时候能把状态记在脑子里. 读起来很快.

用面向对象的, 就得按照写代码人分的层次 /业务的逻辑去了解都干了什么事. ---- 然而其实很简单, 我本可以直接通过代码的变化理解业务, 现在要通过模块 /业务去理解代码, 去理解那个写代码的人.

[firefffffffffly]

粗略思考了一下，我觉得问题关键在于 stateless 和 stateful 之间的区别，面向对象能写出 stateless 的代码，面向过程也可能被写成 stateful，纯函数式编程能真正做到 stateless，但函数式编程又会带来额外的难度。