weixing1531 发表于 2023-3-24 16:44:17

面向过程与面向对象

以下是我的个人理解:
面向过程:模块方法之间通过模块全局变量传递数据,计算效率高


面向对象:成员方法之间通过形参this实例变量传递数据,尽管this默认传址,计算效率有一定的损耗


Module与Type均有封装功能,后者还有绑定功能

编程时如何选择适当的设计模式?

kyra 发表于 2023-3-25 10:20:14

本帖最后由 kyra 于 2023-3-25 10:33 编辑

鱼和熊掌的问题,从来就没有固定答案。

以下是我的个人理解:

面向过程简单、直白。在中小型工程中应用,非常合适。此为 鱼。

大型程序中,变量和函数名容易冲突。大量变量和过程的从属关系过于扁平,不利于管理和理解。
此时需要一定的封装,
Module尽管也能封装,但一个module不能实例化成多个对象。type弥补了这个缺陷。
实际上,type 和module 一直都是相互配合的关系。并不存在取舍问题。
目前比较新的设计模式是:

Module默认private,包含一个或多个public的Type定义。过程函数绑定到type中对外使用(也可private仅供内部使用)。
如果代码量比较大,module依赖层级多。还可以用module procedure定义公共接口,“公共过程的实现”和“私有过程”放在submodule中,避免修改代码后大量其他代码需要重新编译。

以上为熊掌

尽管它仍需要一些代价:默认的 this 指针传递,确实会带来一些额外的资源开销。
但是:
1. 对现在的硬件水平来说,多传递一个参数,绝大部分情况的影响是微乎其微的。
2. 编译器并不会傻乎乎的每次都传递 this 参数,一些小的(频繁被调用的)函数会自动被inline展开,从而一定程度避免不必要的开销。
而较大的函数通常调用频率会低一些,此时多一个 this 参数的影响,就不那么重要了。
3. 相对于代码逻辑的清晰、易读。变量名函数名命名的简洁。我认为大部分情况,额外的开销是值得的。

舍鱼,而取熊掌者也。

当然,对执行效率极端需求的特殊情况下,可以让局部的、重要的、运算量大的代码,回归到面向过程。
毕竟,这两者在局部虽然互斥,但在整个程序里全局是可以兼容的。

页: [1]
查看完整版本: 面向过程与面向对象