面向对象编程
在大学接触面向对象以前,一直都是用面向过程,直到现在写代码还是面向过程居多,学习那会儿经常听到一个论调,说面向对象特别适合大型程序,因为面向过程在大型程序中已经很难管理代码了,于是很好奇到底多大的程序面向过程会出问题,到工作后发现也没什么大不了的,七八十万行的项目照样用纯C做也没问题,大概是还没有接触到吧。不过近几年,虽然偶尔还是会遇到有人翻这个老黄历,但已经少了很多了,相对的听到更多的另一种论点是,不要为了面向对象而面向对象,这话很对,可惜究竟什么时候该用,什么时候不该用,没有严格标准,还是看个人习惯
关于面向过程不适合大型程序这个说法,翻一下语言历史就知道,最早的fortran语言中,如果程序太大,容易有变量名冲突,于是后面algol语言增加了begin...end块结构,限制了变量作用域,这实际是一个名字空间的问题,后来simula在此基础上提出类和对象的概念,后面发展起来,simula还支持继承。最早的起源大概就是这样
需要说明的是,面向对象是一种思想,而不是一种实现,所谓说C++,java是面向对象语言,只是它们的语法等能直接支持而已,C语言语法上不支持,但并不妨碍我们使用这个思想,自己实现类似虚表和虚表指针即可,典型例子:python就是C写的,事实上面向对象语法可以等价转换成面向过程,例如我以前用的sco unix下的C++编译器,实际只是个转换器,先转成等价的C,然后调用系统自带的cc
了解面向对象,一般就从它的三个特点出发:封装、继承和多态
先说封装,这个概念如果从广义来理解,涵盖了很多方面,比如上面说的名字空间,不过为了更明确的讨论,我们讨论“必须用到面向对象思想的封装”,比方说,名字空间这种问题,通过代码规范或者分模块,或者仅仅加入一个跟面向对象不相干的即可解决,C++里即便不写class,名字冲突也能用namespace解决,所以这种封装中面向对象的必要性不大
这里主要是权限的封装,很多人觉得,封装体现在一般支持类的语言都会对类中的属性做权限控制(public,private等),即便实现方式可能有差异。这个说法是对的,但还需要细化讨论,考虑如下代码:
class A
{
private int a;
public int get_a(){return this.a;}
public void set_a(int a){this.a = a;}
}
这是很典型的get/set,不过就这个实现本身来说,跟把a改成public然后直接读写也没啥区别了,唯一的区别是在扩展性上,我们可以在以后的修改中,在set_a方法里面对输入参数做校验或标准化,这就实现了封装。不过即便是这样,get_a还是显得多余,需要get的原因在于语言的权限控制粒度不够细,比方说如果我们加一个readonly关键字,控制一个属性可直接读但不可直接写,那就用不着get了(ruby有这个机制)
上面使用set接口对数据做封装,可以控制非法值,使得外部不能随便设置a,第二个例子更清晰一些,实现一个元素为int的vector:
class IntVector
{
private int[] a;
private int len;
public void push_back(int i){...}
public int pop_back(){...}
}
用数组和长度组合来表示一个vector,下面两个接口的实现非常简单,这个类所有的操作接口都有一个共同特征,就是在调用前和调用后,对象的状态必须一致,也就是说,push_back的时候,要往a里面加数据,必要时还得扩展,然后len也要做相应修改,pop_back同理,不能出现a里面数据的逻辑数量和len不一致的情况,即非法状态,对于一个基本类型来说,可以一条语句修改它的状态,前后状态是一致的,但对于复合类型来说,各属性的含义是相关的,必须保证一致性,这就是封装最重要的意义,可以把复合类型看做整体来操作
再说继承,有时候也叫做派生,但我各人觉得最贴切的说法是java的extends,扩展,即在基类的基础上自己加点或改点东西,实际也是这么实现的。有的地方说继承的最大好处是代码复用,那么不妨看看下面的代码(java):
class A
{
int a;
...//其他属性和接口
}
class B
{
public A a; //构造的时候给其赋值new A()
int b;
...//其他属性和接口
}
void f(A a)
{
...
}
A a;
f(a);
B b;
f(b.a);
这里没有用继承,而是用了包含的方式,一样可以编译通过和执行,跟继承的唯一区别在于,如果B中重写了A的接口,那么没有多态性,仅此而已,事实上如果不需要多态,在C里面用结构体和操作结构体的函数能达到和面向对象一样的效果(上面说的sco unix的C++转换器就这么干的),这时候用继承,只是让你的代码看起来精简些,符合某些个人的习惯或审美罢了,或者反过来说,在我看来,如果一个继承不是为了覆盖基类的接口,那根本就是设计问题
从这个角度来说,完全可以把继承完全改成实现抽象接口,但如果我只想实现其中部分接口,其他接口用“默认行为”,这时候还是需要继承的,但单继承足矣。多继承会有一些麻烦,java把它改成接口是合理的。有了抽象接口,静态类型语言就可以实现鸭子类型,虽然不如动态类型语言那么自由,其依赖的基础就是多态
多态是基于继承的,可以说是面向对象最重要的机制,不过似乎有些人搞混了它和重载,所以还是说下概念:通过一个基类指针(引用)访问一个派生类对象时,调用接口是派生类实际的接口。从这里可以看出,多态是依赖于继承的,如果没有继承,也无所谓多态了(接口实现也是一种继承,虽然语法可能不同)
一个有争议的话题是,python是否有多态,有人认为,多态需要基类引用,而python是动态类型,所以没有,另一些人觉得,虽然是动态类型,但实际上可以看做是所有变量都是object类型,而所有类型都是object的派生类,所以有,这个问题因为出发角度不同,也争不出结论,见仁见智了。多态的具体实现在C++中使用虚函数,具体机制不用费口舌,在python这种动态语言的实现也是类似的,但也有些不同