1,268
社区成员
发帖
与我相关
我的任务
分享面向对象与面向过程是否可以混合使用？
目前正在设计一个软件系统，大致分为具体功能实现，用户界面，配置管理，日志记录几个部分。
本来想在底层用面向过程的方法实现，上层用面向对象。可是有一部分功能实现我实在是想不出用面向对象有什么好处。
首先是效率，虽然有些人经常说面向对象的程序不会比面向过程效率低，可我总觉得要差一点，起码类的构造析构在过程里是不需要的，而这一部分对效率的要求很高。
其次是结构，这一部分和底层结合比较紧密，如果使用对象必须有一个控制模块负责中转，而用过程的方法可以用插件的形式实现，结构很清晰。
最后是实现，如果用对象，系统显得很复杂，特别是控制中转的模块，要兼顾底层和对象两方面；而过程的方法只有几个函数接口，直接与底层挂接，简单明了。
也许是我水平太差吧，没有领会面向对象的精髓。不过我想设计是要随实际情况的不同而变化的。我是觉得理由已经很充分了，但还是来求证一下。这种方法有没有什么负面的效应？会造成多大的影响？如果我这么做是对的话也请说说你的看法，最好是举个例子。因为有人说面向对象与面向过程两种方法混用会带来很多麻烦。
烦请各位前辈不吝赐教！
本来想在底层用面向过程的方法实现，上层用面向对象。可是有一部分功能实现我实在是想不出用面向对象有什么好处。
首先是效率，虽然有些人经常说面向对象的程序不会比面向过程效率低，可我总觉得要差一点，起码类的构造析构在过程里是不需要的，而这一部分对效率的要求很高。
其次是结构，这一部分和底层结合比较紧密，如果使用对象必须有一个控制模块负责中转，而用过程的方法可以用插件的形式实现，结构很清晰。
最后是实现，如果用对象，系统显得很复杂，特别是控制中转的模块，要兼顾底层和对象两方面；而过程的方法只有几个函数接口，直接与底层挂接，简单明了。
也许是我水平太差吧，没有领会面向对象的精髓。不过我想设计是要随实际情况的不同而变化的。我是觉得理由已经很充分了，但还是来求证一下。这种方法有没有什么负面的效应？会造成多大的影响？如果我这么做是对的话也请说说你的看法，最好是举个例子。因为有人说面向对象与面向过程两种方法混用会带来很多麻烦。
烦请各位前辈不吝赐教！
...全文
请发表友善的回复…
发表回复
bohemia 2003-12-23
- 打赏
- 举报
其实无论是面向对象还是面向过程，其最终的目的还是为了解决问题，不论我们采用哪种方法，都各有利弊，我们不要过分的注重方法，而是要根据实际情况去选择适合 的方法，而不是对某个问题一定得采用这个或那个方法，我们的目的是解决问题，甚至有时候我们完全可以采用两种方法的混用，这个完全可以，但我还是比较同意美国人的方法，先看问题，然后再总结方法，再运用到问题的解决当中，这样，我觉得是最好的，你们认为呢/？/
wltsui 2003-12-23
- 打赏
- 举报
关键是面向对象的思想！
BirdGu 2003-12-22
- 打赏
- 举报
从楼主对OO的认识来看，还是完全、百分百的用面向过程吧。
despird 2003-12-22
- 打赏
- 举报
现代中国开发的design pattern是：
前人OO，后人在OO出来的东东上面PO，因此就有了传说中的系统分析员和程序员。
前人OO，后人在OO出来的东东上面PO，因此就有了传说中的系统分析员和程序员。
carrotmin 2003-12-22
- 打赏
- 举报
我想问一个问题
有可能这两种方法不混合使用吗
有可能这两种方法不混合使用吗
asj 2003-12-22
- 打赏
- 举报
不是写了顺序执行的代码就是面向过程了，所谓“面向”就是着眼点在哪里，就是以什么样的思维方式来进行程序的组织。如果因为会调用OP过程就是结合了OP的话，那么最终的代码都会成为二进制，是否也要叫做面向二进制呢？而如果有要将OO和OP结合的想法，一般来说都是遇到了不知道该如何通过OO解决的问题而希望采取旧有的习惯，这和在IF语句中夹杂GOTO一样，不是两者的结合，而是向最差的情况看齐。
而具体的程序中某些模块是否是OO或OP的情况，要看你着眼进行设计的主体层面是什么。比如在原有的函数库外部编写一个Facade作为访问的接口，用来隔离你的程序和函数库间的依赖，那么这种设计是OO的。相反，如果没有贯穿面向对象的设计原则，不将利用抽象封装多态来处理逻辑，那么就算是使用完全面向对象的语言，操作面向对象编写的组件或类库，这样写出的程序仍是面向过程的。最典型的例子就是因为JAVA中没有全局函数，所以编写一个全局的工具函数类，这是通过OO工具笨拙的实现OP思想，而不是两者结合。
而具体的程序中某些模块是否是OO或OP的情况，要看你着眼进行设计的主体层面是什么。比如在原有的函数库外部编写一个Facade作为访问的接口，用来隔离你的程序和函数库间的依赖，那么这种设计是OO的。相反，如果没有贯穿面向对象的设计原则，不将利用抽象封装多态来处理逻辑，那么就算是使用完全面向对象的语言，操作面向对象编写的组件或类库，这样写出的程序仍是面向过程的。最典型的例子就是因为JAVA中没有全局函数，所以编写一个全局的工具函数类，这是通过OO工具笨拙的实现OP思想，而不是两者结合。
FlySoftter 2003-12-22
- 打赏
- 举报
实现完全面向对象是不可能的，也是没有任何意义的
shadowstar 2003-12-22
- 打赏
- 举报
怎么算结合？
VCL算不算OO与OP结合？
单就这一个模块来说，要么写成API，要么写成Interface，但不管怎么样都要调用OP过程。如果就整个软件系统来说，就有的部分用OO，有的部分用OP了，我不觉得这有什么不妥。
其实发这个贴子主要目的是希望讨论一下OO和OP各自的优势在哪里，以及如何有效的利用它们的优势，设计一个高效、稳定、易扩展、易维护的系统。
VCL算不算OO与OP结合？
单就这一个模块来说，要么写成API，要么写成Interface，但不管怎么样都要调用OP过程。如果就整个软件系统来说，就有的部分用OO，有的部分用OP了，我不觉得这有什么不妥。
其实发这个贴子主要目的是希望讨论一下OO和OP各自的优势在哪里，以及如何有效的利用它们的优势，设计一个高效、稳定、易扩展、易维护的系统。
FlySoftter 2003-12-22
- 打赏
- 举报
我要说的是，面向对象这种技术虽然所谓时髦，但大家不应该一味的强调它，不能不分场合的对其加以利用，关于楼主的问题，我个人认为目前还没有完全面向对象的语言出现，也就是说，虽然现在的编程工具很多都采用面向对象的结构，但功能的具体实现还是以过程为主线来展开的，所以，我要说的是，没有真正好的东西，有利就有弊，找到一个平衡点才是最重要的
ozzzzzz 2003-12-22
- 打赏
- 举报
shadowstar(天作棋盘星作子，谁人敢下？)
你看看我的回复，就知道BirdGu(鲲鹏)为什么这么说了。他只是更直接的告诉了你。
其实对OO是不是真理解，你可以看他是不是认为OO可以和PO结合。
你看看我的回复，就知道BirdGu(鲲鹏)为什么这么说了。他只是更直接的告诉了你。
其实对OO是不是真理解，你可以看他是不是认为OO可以和PO结合。
shadowstar 2003-12-22
- 打赏
- 举报
BirdGu(鲲鹏)打击我来了？
就算我水平不行，要么批评一下哪里不行，要么说说该怎么做，况且只是这个贴子……
这样的回复实在是太无聊了~~
就算我水平不行，要么批评一下哪里不行，要么说说该怎么做，况且只是这个贴子……
这样的回复实在是太无聊了~~
asj 2003-12-21
- 打赏
- 举报
强烈反对所谓结合的说法，这样就和说“要结合结构话编程和GOTO语句的优点”一样，可能只是让习惯了旧方法的人感到安慰而已。而所谓的结合，不过是旧习惯的遗留而已。
面向对象是在面向过程的编程的基础上进一步发展而来的，所以没有什么结合的必要，因为一般性的原则，已经在这种发展中得以保留，已经不适应的作法在新的方法中被明确的反对并提供了替代的方案。
面向对象是在面向过程的编程的基础上进一步发展而来的，所以没有什么结合的必要，因为一般性的原则，已经在这种发展中得以保留，已经不适应的作法在新的方法中被明确的反对并提供了替代的方案。
shadowstar 2003-12-20
- 打赏
- 举报
回复：scalene(南瓜汤)
首先是效率
------------------------------------------------------------------------------
你说的几本C++的书我都看过，的确可以用来提高C++程序的效率。不过我的程序是要在多线程下进行大量的运算，每一个运算循环都要将对象构造析构。构造析构只是内存的分配和释放，我没具体实验过，不知道会有多大的影响。
其次是结构
------------------------------------------------------------------------------
你说的“更”简单我不太赞同。Adapter，Facade我看了一下，我觉得我用面向对象的设计应该属于Proxy+Facade。底层->Proxy->Facade->功能实现。《设计模式》一直没机会读，真的不是我懒，是要看的书太多了。用到什么了就看这方面的书，在实践中学习是最好的方法：P
最后是实现
------------------------------------------------------------------------------
OO对某些实现是不太适合的，这种情况下最好的方法就是用角本。记得这是哪个老外的牛人说过的，我会考虑在下一个版本中用角本实现。我说的复杂只是Proxy的实现比较复杂，不会有暴露接口类过多的问题。不过有时候一下想明白真的是很难，就想上次我实现的一个类，用了2000多行的代码，后来把这个类折分成5个类，另外实现了2个辅助内存管理类，代码总和基本没变，而且更容易扩展。
没有什么是绝对不可以的。
-------------------------------------------------------------------------------
多谢你的忠告！
“90%以上OO比PO更有优势”这点我同意！
首先是效率
------------------------------------------------------------------------------
你说的几本C++的书我都看过，的确可以用来提高C++程序的效率。不过我的程序是要在多线程下进行大量的运算，每一个运算循环都要将对象构造析构。构造析构只是内存的分配和释放，我没具体实验过，不知道会有多大的影响。
其次是结构
------------------------------------------------------------------------------
你说的“更”简单我不太赞同。Adapter，Facade我看了一下，我觉得我用面向对象的设计应该属于Proxy+Facade。底层->Proxy->Facade->功能实现。《设计模式》一直没机会读，真的不是我懒，是要看的书太多了。用到什么了就看这方面的书，在实践中学习是最好的方法：P
最后是实现
------------------------------------------------------------------------------
OO对某些实现是不太适合的，这种情况下最好的方法就是用角本。记得这是哪个老外的牛人说过的，我会考虑在下一个版本中用角本实现。我说的复杂只是Proxy的实现比较复杂，不会有暴露接口类过多的问题。不过有时候一下想明白真的是很难，就想上次我实现的一个类，用了2000多行的代码，后来把这个类折分成5个类，另外实现了2个辅助内存管理类，代码总和基本没变，而且更容易扩展。
没有什么是绝对不可以的。
-------------------------------------------------------------------------------
多谢你的忠告！
“90%以上OO比PO更有优势”这点我同意！
scalene 2003-12-20
- 打赏
- 举报
shadowstar (天作棋盘星作子，谁人敢下？) :回答你的几个问题。
首先是效率，虽然有些人经常说面向对象的程序不会比面向过程效率低，可我总觉得要差一点，起码类的构造析构在过程里是不需要的，而这一部分对效率的要求很高。
------------------------------------------------------------------------------
构造析构函数本身的开销对于现在的计算机来说是微不足道的，除了极特殊的情况，一般不会影响效率。如果出现效率问题，一般是由于你的对象设计目标有问题，导致存在很多不必要的资源初始化/释放过程；比如说数据库应用，如果每个对象都要进行数据库连接/释放，自然会有效率问题。如果你确实进行过性能检查，确定是构造析构函数本身的函数调用开销导致性能问题，那么我假定你使用的是C++，因为一般这样性能攸关的程序都会选择C++来做。可以去看看Inside C++，Effective C++，More Effective C++，有很多提高性能方面的技巧。
其次是结构，这一部分和底层结合比较紧密，如果使用对象必须有一个控制模块负责中转，而用过程的方法可以用插件的形式实现，结构很清晰。
------------------------------------------------------------------------------
OO程序实现插件方式更简单清晰，有很多现成的模式，比如Adapter，Facade等。推荐读一下《设计模式》。
最后是实现，如果用对象，系统显得很复杂，特别是控制中转的模块，要兼顾底层和对象两方面；而过程的方法只有几个函数接口，直接与底层挂接，简单明了。
-------------------------------------------------------------------------------
OO系统中设计模块时要选择好暴露哪些接口类。如果你的模块设计目标清晰，那末需要暴露的类就不会很多。而接口类之间由于有一定关联关系（比如，User-(have)->Priority），单个的类public的方法也会有一些自然的语义上的联系（比如，Person类有公共方法GetName()，GetAge()等），所以理解上一般会比面向过程的模块更容易一些。显得复杂只能说是设计的问题，导致需要暴露的接口类过多，关系不明确。
面向对象与面向过程是否可以混合使用？
-------------------------------------------------------------------------------
没有什么是绝对不可以的。如果某个单独模块，由于特殊原因必须采用不同的策略，那么也不会有什么太大的问题。但是如果同一模块内部，同时使用OO和PO，那么会（1）首先，需要很高的设计和实现技巧，才能够同时发挥两者的长处，而不会造成负面影响（比如PO中常用的全局变量，宏，你需要保证它们不向OO部分渗透；同样，PO程序中对于一些内部类的不当使用也会很容易导致结构僵化，而很难检查这种使用是否恰当）；（2）其次，因为技巧性要求很高，对于其他人阅读你的代码或设计带来了麻烦；（3）目前OO和PO都有其独特的建模工具，在Code Style上也有一定的区别，以及Unit Test工具等等；那么你在选择这些工具时就会受到很大的限制。
除了比较简单的模块，面向过程会比面向对象实现效率上有一定优势，以及非常底层的系统级开发OO编译器不支持，或者是性能极端重要的情况，90%以上OO比PO更有优势。
首先是效率，虽然有些人经常说面向对象的程序不会比面向过程效率低，可我总觉得要差一点，起码类的构造析构在过程里是不需要的，而这一部分对效率的要求很高。
------------------------------------------------------------------------------
构造析构函数本身的开销对于现在的计算机来说是微不足道的，除了极特殊的情况，一般不会影响效率。如果出现效率问题，一般是由于你的对象设计目标有问题，导致存在很多不必要的资源初始化/释放过程；比如说数据库应用，如果每个对象都要进行数据库连接/释放，自然会有效率问题。如果你确实进行过性能检查，确定是构造析构函数本身的函数调用开销导致性能问题，那么我假定你使用的是C++，因为一般这样性能攸关的程序都会选择C++来做。可以去看看Inside C++，Effective C++，More Effective C++，有很多提高性能方面的技巧。
其次是结构，这一部分和底层结合比较紧密，如果使用对象必须有一个控制模块负责中转，而用过程的方法可以用插件的形式实现，结构很清晰。
------------------------------------------------------------------------------
OO程序实现插件方式更简单清晰，有很多现成的模式，比如Adapter，Facade等。推荐读一下《设计模式》。
最后是实现，如果用对象，系统显得很复杂，特别是控制中转的模块，要兼顾底层和对象两方面；而过程的方法只有几个函数接口，直接与底层挂接，简单明了。
-------------------------------------------------------------------------------
OO系统中设计模块时要选择好暴露哪些接口类。如果你的模块设计目标清晰，那末需要暴露的类就不会很多。而接口类之间由于有一定关联关系（比如，User-(have)->Priority），单个的类public的方法也会有一些自然的语义上的联系（比如，Person类有公共方法GetName()，GetAge()等），所以理解上一般会比面向过程的模块更容易一些。显得复杂只能说是设计的问题，导致需要暴露的接口类过多，关系不明确。
面向对象与面向过程是否可以混合使用？
-------------------------------------------------------------------------------
没有什么是绝对不可以的。如果某个单独模块，由于特殊原因必须采用不同的策略，那么也不会有什么太大的问题。但是如果同一模块内部，同时使用OO和PO，那么会（1）首先，需要很高的设计和实现技巧，才能够同时发挥两者的长处，而不会造成负面影响（比如PO中常用的全局变量，宏，你需要保证它们不向OO部分渗透；同样，PO程序中对于一些内部类的不当使用也会很容易导致结构僵化，而很难检查这种使用是否恰当）；（2）其次，因为技巧性要求很高，对于其他人阅读你的代码或设计带来了麻烦；（3）目前OO和PO都有其独特的建模工具，在Code Style上也有一定的区别，以及Unit Test工具等等；那么你在选择这些工具时就会受到很大的限制。
除了比较简单的模块，面向过程会比面向对象实现效率上有一定优势，以及非常底层的系统级开发OO编译器不支持，或者是性能极端重要的情况，90%以上OO比PO更有优势。
miszyf 2003-12-20
- 打赏
- 举报
两种方法都各有所长，结合双方优点是重要的。
shadowstar 2003-12-20
- 打赏
- 举报
多谢 ozzzzzz！
其实只是具体处理插件使用C来实现，同一个模块里不会使用两种方法，不知道这算不算是混合使用？
本来打算用COM，基于我上面说的原因，改为每个插件DLL实现一组函数，相当于把 class_name.method 改成了 module_name_procedure，不知道算不算是用了面向对象的方法？
其实只是具体处理插件使用C来实现，同一个模块里不会使用两种方法，不知道这算不算是混合使用？
本来打算用COM，基于我上面说的原因，改为每个插件DLL实现一组函数，相当于把 class_name.method 改成了 module_name_procedure，不知道算不算是用了面向对象的方法？
showerXP 2003-12-20
- 打赏
- 举报
学习。
ozzzzzz 2003-12-20
- 打赏
- 举报
效率问题？我们常说面向对象的效率不如面向过程的效率高，主要是说面向对象的语言不如面向过程的语言效率高。但是我们知道面向对象的分析和设计方法与面向对象的语言不是有必然的联系的。至少你应该经常看到非常多的人用JAVA写面向过程的程序。而其实用C以至于ASM都可以写出很好的体现面向对象封装风格的程序。而很多初学者有这样的看法，JAVA不能调用底层，所以不如CPP，而CPP又不如C，C不如ASM，ASM不如机器语言。当然有一些应用只能依靠机器语言来实现，但是这并不能说明机器语言就是最好的语言。而效能问题往往也是这样，你用ASM可能会写的程序更快，但是你写程序的时间却更常。而C和CPP也是一样。对于系统效能的瓶颈往往只是一小部分的代码，我们应该使用profiler去找到这些部分，作有针对性的优化。而不是在一开始就放弃强大的工具，进行底层的工作。
而结构问题也很奇怪。结构其实是人对于事物作分析的划分方法，事物本身并不存在结构。比如对于人身体的划分，我们可以按照器官划分为心脏、肝脏等等，也可以安装组织划分为肌肉、骨骼等等。我们之所以要划分结构，是因为我们习惯把问题分割处理。面向对象和面向过程就是分割的两种方式。面向对象的方法是人类习惯的思维方法，它更好的支持增量的开发。你可以把问题划分为一些概念，然后各个分析。也许你会跳跃，也许你会无逻辑，也许你会反复，也许你会类比，这是人类思考问题的习惯。而机器解决问题的习惯则是线性的，逻辑严密的，你不能跨过一去解决二。但是人类就是一个非线性的思考机器，大脑过虑大量的信息，只去注意有兴趣的极少极少的信息。所以人类才可以战胜计算能力大大强于自己的电脑。你觉得面向对象的方法不能适合底层的结构，只是由于你对于结构的划分不是按照面向对象的方法进行的。
最后是实现问题。这本不应该是问题，因为面向对象最大的优势就是各自掌管各自的职责，也就是单一职责原则（SRP）。所谓控制中转的模块会更复杂，往往就说明类的职责划分不清，正好说明你在使用面向过程的方法解决问题。
其实我很少见到面向过程和面向对象方法共同使用的人，大多数说两者可以结合使用的人往往是根本就不懂面向对象的人，当然也有个别的人其实是在说面向对象的方法可以使用面向过程的语言实现（比如不常露脸的w_rose）。而实际上面向过程在处理简单的问题时要比面向对象来得便宜。但是变化已经是现代软件的必须要考虑的情况，而变化带来的就是更复杂。
而结构问题也很奇怪。结构其实是人对于事物作分析的划分方法，事物本身并不存在结构。比如对于人身体的划分，我们可以按照器官划分为心脏、肝脏等等，也可以安装组织划分为肌肉、骨骼等等。我们之所以要划分结构，是因为我们习惯把问题分割处理。面向对象和面向过程就是分割的两种方式。面向对象的方法是人类习惯的思维方法，它更好的支持增量的开发。你可以把问题划分为一些概念，然后各个分析。也许你会跳跃，也许你会无逻辑，也许你会反复，也许你会类比，这是人类思考问题的习惯。而机器解决问题的习惯则是线性的，逻辑严密的，你不能跨过一去解决二。但是人类就是一个非线性的思考机器，大脑过虑大量的信息，只去注意有兴趣的极少极少的信息。所以人类才可以战胜计算能力大大强于自己的电脑。你觉得面向对象的方法不能适合底层的结构，只是由于你对于结构的划分不是按照面向对象的方法进行的。
最后是实现问题。这本不应该是问题，因为面向对象最大的优势就是各自掌管各自的职责，也就是单一职责原则（SRP）。所谓控制中转的模块会更复杂，往往就说明类的职责划分不清，正好说明你在使用面向过程的方法解决问题。
其实我很少见到面向过程和面向对象方法共同使用的人，大多数说两者可以结合使用的人往往是根本就不懂面向对象的人，当然也有个别的人其实是在说面向对象的方法可以使用面向过程的语言实现（比如不常露脸的w_rose）。而实际上面向过程在处理简单的问题时要比面向对象来得便宜。但是变化已经是现代软件的必须要考虑的情况，而变化带来的就是更复杂。
chinapcer 2003-12-19
- 打赏
- 举报
整体上的考虑还是用面向对象的思想会好很多，至于底层的一些处理，在类的划分上不那么细，把整个大的过程都写到类的方法中去就可以了。面向对象和面向过程并不是对立的，面向对象是从整理上把握系统构成方式的一种方法，而所谓对象，到最终实现的方法级别上，也还是过程
WhishtThinking 2003-12-19
- 打赏
- 举报
支持 Fusuli(大刀向鬼子们的头上砍去) 的观点！
所有的方法都不是绝对的，否定一个东西不等于推翻它。
我们现在反对封建思想，那么你能够说封建思想中的所有东西都是垃圾吗？你能说所有现代文明都比以前的封建社会文明进步吗？都好吗？
人和低级动物、机器之间的差距就在于人是有思想的动物。思想决定了人们能够不断地创新。现在人工智能方面最大的难度就是将人的思想实现。当然，如果机器能够具有人类的思想，那么人类存在的必要也就微乎其微了！！！
总之一句话，以适用为本。
所有的方法都不是绝对的，否定一个东西不等于推翻它。
我们现在反对封建思想，那么你能够说封建思想中的所有东西都是垃圾吗？你能说所有现代文明都比以前的封建社会文明进步吗？都好吗？
人和低级动物、机器之间的差距就在于人是有思想的动物。思想决定了人们能够不断地创新。现在人工智能方面最大的难度就是将人的思想实现。当然，如果机器能够具有人类的思想，那么人类存在的必要也就微乎其微了！！！
总之一句话，以适用为本。
加载更多回复（2）
