论坛首页 综合技术论坛

面向对象之弊,面向过程之优

浏览 48558 次
该帖已经被评为良好帖
作者 正文
   发表时间:2010-07-15   最后修改:2010-07-15
yangguo 写道
可惜不能投新手帖。

随便找几个毫无意义的例子就出来否定OO,可笑可笑。
扩展性和适应变化正是OO最大优点,竟然说不如PO,简直一派胡言。
劝君学习一下设计模式再出来发表高论,免得误人子弟,怡笑大方。


开头就说了,本文并不是要否定OO,而是要给PO更多的肯定。
0 请登录后投票
   发表时间:2010-07-15  
icefishc 写道
喂, 过程和函数是2个东西

随便啦。
0 请登录后投票
   发表时间:2010-07-15  
1 全局变量在OO里可以用单例实现
2 回调函数也是“对象”,如果你真的是个OOer
3 OO的长处不是灵活,而是解决复杂问题

OO的根本是要求你有OO的思维,把一切看成对象,特别是问题领域。

0 请登录后投票
   发表时间:2010-07-15  
觉得是例子中代码实现的问题, 换种实现,oo就能体现优点
0 请登录后投票
   发表时间:2010-07-15  
怎么不说说面向对象的面向接口编程的优势啊。
0 请登录后投票
   发表时间:2010-07-15  
yangguo 写道
可惜不能投新手帖。

随便找几个毫无意义的例子就出来否定OO,可笑可笑。
扩展性和适应变化正是OO最大优点,竟然说不如PO,简直一派胡言。
劝君学习一下设计模式再出来发表高论,免得误人子弟,怡笑大方。


要不,你来说说看...
0 请登录后投票
   发表时间:2010-07-15  
ray_linn 写道
恩,Java不是OO语言的全部吧。回调函数在C#里就很处理并不尴尬,(当然用C++搞就更不尴尬了),从楼主的例子上看,只能说Java太固步自封了,在C#出来之前一直没有进步。

class A
{
      public event ProcessDelegate ProcessEvent;
}      

var a =new A(); 
a.ProcessEvent += new ProcessDelegate(t_ProcessEvent);


也可以这样搞
        class A<T>
        {
            public void MethodA(Func<T> fun)
            {
                fun.Invoke();
            }
        }


第二个问题就更简单了,C#中有扩展方法,我们给A,B做个伪接口
interface Fake{}
Class A :Fake{}
Class B :Fake{}
static Class Ext
{
   TypeA MehtodA(this Fake ojb, ParamA){}
   TypeB MethodB(this Fake obj, ParamB){}
}

调用时
A.MethodA(...) A.MethodB(...), B.MethodA(...),B.MethodB(...); 如果问题再具体点,还有更多有趣的方法。




C#真神奇。C#加入这些特性,是件好事。

第一段通过 event关键字,+=操作符让ProcessEvent成为了一个event dispatcher,ProcessDelegate是否就是callback函数?ProcessDelegate是一个类?

但我们是否应该反思,是不是因为OO的设计模式出现了问题,所以才需要加入这些特性的呢?我们是不是更宁愿使用编译器带来的特性帮助我们————用简单的代码(event关键字,+=操作符)————编译出复杂的机制(基于OO的事件分发系统)————来实现简单的功能(其实就用函数指针或引用就行了),而不愿意偶尔改变一下思路,使用PO的方式来实现简单的功能呢?

第二段像反射。
发现越是牛逼的项目,反射用的就越多,反射的本质是什么?反射的目的是进入到OO的结构内部,挖掘所需信息,调用所需函数。对于PO来说,根本就不存在反射这个概念。反射的出现与流行证明了人们尤其是牛逼的人们受不了某种限制,虽然他们也许都没有意识到这种限制来自于OOP。

第三段像是根据this关键字在编译阶段注入方法。
什么叫编译阶段注入方法,就是OO在语法上不允许在2没有继承关系的类上通用的方法,通过在目标代码中由编译器强行插入函数指针的方式来实现无继承关系的2个类的通用。

类似的还有,AOP概念,mock object,其实在PO里面简单的HOOK就可以实现。

其实我们已经知道,总有那么一些情况,我们用类继承,多重继承,没有办法解决问题,所以有了 Adapter,Bridge,Decorator,Facade 等等这些设计模式来帮助我们解决问题,现在C#给了我们另一种选择,编译器增强“模式”,这些都是OO所带来的问题所引申出的概念。

C#带来的编译器增强“模式”,的确是个效率更高的好模式,但会带来语法越来越复杂的问题。
0 请登录后投票
   发表时间:2010-07-15  
ipeer 写道
觉得是例子中代码实现的问题, 换种实现,oo就能体现优点


换种实现是OO常遇到的问题,类结构会被多次“换种实现”,PO虽然第一次累点,但很少需要“换种实现”,所以我说“OO重构麻烦”
0 请登录后投票
   发表时间:2010-07-15   最后修改:2010-07-15
jasongreen 写道
icefishc 写道
喂, 过程和函数是2个东西

随便啦。


这么说吧,OO 是命令式的延伸,不能脱离命令式编程而存在,归根到底是 imperative paradigm 的语法糖。
如果脱离了过程语句(if, for, while ...),OO 只能做架构,写不了程序。

相比之下函数式编程就简单多了,不需要 OO 和指令式语句就能自成体系,既能架构,又能程序。

http://www.powerset.com/explore/semhtml/Programming_paradigm
0 请登录后投票
   发表时间:2010-07-15   最后修改:2010-07-15
night_stalker 写道
jasongreen 写道
icefishc 写道
喂, 过程和函数是2个东西

随便啦。


这么说吧,OO 是过程的延伸,不能脱离命令式编程而存在,归根到底是 imperative paradigm 的语法糖。
如果脱离了过程语句(if, for, while ...),OO 只能做架构,写不了程序。

相比之下函数式编程就简单多了,不需要 OO 和指令式语句就能自成体系,既能架构,又能程序。

http://www.powerset.com/explore/semhtml/Programming_paradigm

这么说吧,“函数式编程”是属于“面向过程”的一种类似“设计模式”的东西。
0 请登录后投票
论坛首页 综合技术版

跳转论坛:
Global site tag (gtag.js) - Google Analytics