面向对象的三个基本特征

面向对象的三个基本特征是:封装、继承、多态。
o_OOBase.gif
封装
封装最好理解了。封装是面向对象的特征之一,是对象和类概念的主要特性。
封装,也就是把客观事物封装成抽象的类,并且类可以把自己的数据和方法只让可信的类或者对象操作,对不可信的进行信息隐藏。
继承
面向对象编程 (OOP) 语言的一个主要功能就是“继承”。继承是指这样一种能力:它可以使用现有类的所有功能,并在无需重新编写原来的类的情况下对这些功能进行扩展。
通过继承创建的新类称为“子类”或“派生类”。
被继承的类称为“基类”、“父类”或“超类”。
继承的过程,就是从一般到特殊的过程。
要实现继承,可以通过“继承”(Inheritance)和“组合”(Composition)来实现。
在某些 OOP 语言中,一个子类可以继承多个基类。但是一般情况下,一个子类只能有一个基类,要实现多重继承,可以通过多级继承来实现。
 
继承概念的实现方式有三类:实现继承、接口继承和可视继承。
Ø         实现继承是指使用基类的属性和方法而无需额外编码的能力;
Ø         接口继承是指仅使用属性和方法的名称、但是子类必须提供实现的能力;
Ø         可视继承是指子窗体(类)使用基窗体(类)的外观和实现代码的能力。
在考虑使用继承时,有一点需要注意,那就是两个类之间的关系应该是“属于”关系。例如,Employee 是一个人,Manager 也是一个人,因此这两个类都可以继承 Person 类。但是 Leg 类却不能继承 Person 类,因为腿并不是一个人。
抽象类仅定义将由子类创建的一般属性和方法,创建抽象类时,请使用关键字 Interface 而不是 Class。
OO开发范式大致为:划分对象→抽象类→将类组织成为层次化结构(继承和合成) →用类与实例进行设计和实现几个阶段。
 
多态
多态性(polymorphisn)是允许你将父对象设置成为和一个或更多的他的子对象相等的技术,赋值之后,父对象就可以根据当前赋值给它的子对象的特性以不同的方式运作。简单的说,就是一句话:允许将子类类型的指针赋值给父类类型的指针。
实现多态,有二种方式,覆盖,重载。
覆盖,是指子类重新定义父类的虚函数的做法。
重载,是指允许存在多个同名函数,而这些函数的参数表不同(或许参数个数不同,或许参数类型不同,或许两者都不同)。
其实,重载的概念并不属于“面向对象编程”,重载的实现是:编译器根据函数不同的参数表,对同名函数的名称做修饰,然后这些同名函数就成了不同的函数(至少对于编译器来说是这样的)。如,有两个同名函数:function func(p:integer):integer;和function func(p:string):integer;。那么编译器做过修饰后的函数名称可能是这样的:int_func、str_func。对于这两个函数的调用,在编译器间就已经确定了,是静态的(记住:是静态)。也就是说,它们的地址在编译期就绑定了(早绑定),因此,重载和多态无关!真正和多态相关的是“覆盖”。当子类重新定义了父类的虚函数后,父类指针根据赋给它的不同的子类指针,动态(记住:是动态!)的调用属于子类的该函数,这样的函数调用在编译期间是无法确定的(调用的子类的虚函数的地址无法给出)。因此,这样的函数地址是在运行期绑定的(晚邦定)。结论就是:重载只是一种语言特性,与多态无关,与面向对象也无关!引用一句Bruce Eckel的话:“不要犯傻,如果它不是晚邦定,它就不是多态。”
那么,多态的作用是什么呢?我们知道,封装可以隐藏实现细节,使得代码模块化;继承可以扩展已存在的代码模块(类);它们的目的都是为了——代码重用。而多态则是为了实现另一个目的——接口重用!多态的作用,就是为了类在继承和派生的时候,保证使用“家谱”中任一类的实例的某一属性时的正确调用。
 
概念讲解
泛化( Generalization
o_Generalization.gif
图表 1 泛化
在上图中,空心的三角表示继承关系(类继承),在 UML 的术语中,这种关系被称为泛化( Generalization )。 Person( ) 是基类, Teacher( 教师 ) Student( 学生 ) Guest( 来宾 ) 是子类。
若在逻辑上B是A的“一种”,并且A的所有功能和属性对B而言都有意义,则允许B继承A的功能和属性。
例如, 教师是人, Teacher Person 的“一种”( a kind of )。那么类 Teacher可以从类 Person派生(继承)。
如果A是基类,B是A的派生类,那么B将继承A的数据和函数。
如果类A和类B毫不相关,不可以为了使B的功能更多些而让B继承A的功能和属性。
若在逻辑上B是A的“一种”(a kind of ),则允许B继承A的功能和属性。
 
聚合(组合)
o_aggregationBase.gif
图表 2 组合
若在逻辑上A是B的“一部分”(a part of),则不允许B从A派生,而是要用A和其它东西组合出B。
例如,眼(Eye)、鼻(Nose)、口(Mouth)、耳(Ear)是头(Head)的一部分,所以类Head应该由类Eye、Nose、Mouth、Ear组合而成,不是派生(继承)而成。
 
聚合的类型分为无、共享( 聚合)、复合( 组合)三类。
 
聚合( aggregation
 
o_aggregation.gif
图表 3 共享
上面图中,有一个菱形(空心)表示聚合( aggregation )(聚合类型为共享),聚合的意义表示 has-a 关系。聚合是一种相对松散的关系,聚合类 B 不需要对被聚合的类 A 负责。
 
组合( composition
o_composition.gif
图表 4 复合
这幅图与上面的唯一区别是菱形为实心的,它代表了一种更为坚固的关系 —— 组合( composition )(聚合类型为复合)。组合表示的关系也是 has-a ,不过在这里, A 的生命期受 B 控制。即 A 会随着 B 的创建而创建,随 B 的消亡而消亡。
 
依赖 (Dependency)
o_Dependency.gif
图表 5 依赖
这里 B A 的关系只是一种依赖 (Dependency) 关系,这种关系表明,如果类 A 被修改,那么类 B 会受到影响。

 

 

UML对很多人来说应该不是一个陌生的概念,这一两年来,UML被大家越来越多的讨论着。本来UML跟我这个主题似乎并不能扯上多大的关系(它是语言无关的,甚至可以说其本身就是一种语言——用于交流的)。我在此谈到它有两个目的:
1. UML是针对面向对象软件开发的,而C++正是这样的一种语言
2. UML在设计中被越来越多的使用着,而下一篇杂谈准备讨论设计模式,如果不了解UML,那么无法进行下去

UML,全称:Unified Modeling Language,其目的是为了对软件密集型的制品进行可视化、详述、构造和文档化的图形语言。UML是依据许多前人的思想总结出的成果,1997年被OMG通过并成为标准(所以在《设计模式》书中如果你看到与标准不一样的地方,不要奇怪,那本书是95年的)。关于UML的历史和更详细的描述,可以参考《UML 参考手册》。UML主要由一系列视图组成,其中包括静态视图(Static view),用例视图(Use case view)活动视图(Activity view)等,不同的图用处自然也不一样,而对开发人员来讲(或者说为我的下一篇来说),更重要的应该是静态视图中的类图(class diagram)和交互视图(Interaction view)中的顺序图(Sequence diagram),请注意view和diagram的区别。

类图
静态视图说明了对象的结构,其中最常用的就是类图,类图可以帮助我们更直观的了解一个系统的体系结构,有时侯,描述系统快照的对象图(Object diagram)也是很有用的。在这里,我们主要介绍类图,下面的图就是一个简单的类图:

在类图中,类由矩形框来表示,如上图中,定义了4个类,分别为Base、A、B、C,类之间的关系通过各种线条和其他符号来表示,在上图中,空心的三角表示继承关系,在UML的术语中,这种关系被称为泛化(Generalization),所以上面的类用等价代码表示为:
class Base{…};
class A:public Base{…};
class B:public Base{…};
class C:public Base{…};

我们再看下一幅图:

这幅图与上幅几乎没有什么区别,唯一的不同就是Base类中增加了成员,一个私有的integer _x(UML术语为property)和一个公有的fun()的函数(method),是否需要这些类的内部细节UML本身并没有限制,完全取决于你自己如何使用,UML的用处在于帮助你了解系统,所以只要你自己觉得足够清楚,那么够了,不要再复杂了。
接着看第三幅图:

上面图中的箭头表示一种关系,箭头另一边有一个菱形(空心)表示聚合(aggregation),聚合的意义表示has-a关系,其等价代码如下:
class A{…};
class B{ A* theA;…};
聚合是一种相对松散的关系,聚合类B不需要对被聚合的类A负责。
下面的图:

这幅图与上面的唯一区别是菱形为实心的,它代表了一种更为坚固的关系——组合(composition)。组合表示的关系也是has-a,不过在这里,A的生命期受B控制,通常情况,等价代码如下:
class A{…};
class B{A theA;…};
即A会随着B的创建而创建,随B的消亡而消亡。

下图:

这里B与A的关系只是一种依赖关系,这种关系表明,如果类A被修改,那么类B会受到影响,一个简单的例子就是:
class A{…};
class B{fun(A params);…};

常用的关系就是我们上面用的这些,通过这些关系和类表示的类图,我们可以用图形化的方式描述一个系统的设计部分,当你习惯使用UML后,你会发现,这往往比你告诉同伴某某类从某某类派生,派生类又和某某类具有什么关系容易的多。

顺序图:
UML中另外一个常用的图形就是交互视图中的顺序图,在以往的过程化语言中,我们通常使用流程图来描述一个函数(系统)是如何工作的,而在面向对象的系统中,这显然是不可行的,而顺序图正是来解决这个问题的。
假设有如下的伪代码:

class circle{
public:
void fillcolor()
{
// ...
}
void draw()
{
fillcolor();
}
};
class window{
public:
void drawcircle()
{
_circle.draw();
}
private:
circle _circle;
};

对于下面的调用:
window wnd;
wnd.drawcircle();
对应的顺序图如下:

 

图中上方的方块表示参与的对象,垂直的虚线表示对象的生命线,方框表示激活,其中箭头表示了一个调用消息(也可以有回送return),如果是异步的消息,则用半箭头表示,其中draw表示了一个自调用(self call)

至此,UML中最常用的(从开发人员的角度),当然UML的内容远远不只这些,这里的介绍只是一些简单的概括,并且UML本身也在不断的发展之中,无论怎样,我觉得UML会越来越多的深入我们的开发过程中,特别是对下一篇我们要介绍的设计模式而言,类图是主要的描述工具(到那个时候你会体会到UML描述的优越)。
如果你看过《设计模式》着本书,你会发现与我上面所描述的有一些细微的不同,不要紧张,《设计模式》是GOF95年的作品,那时候UML还没有形成,而且,其中也明确那是OMT方法(Jim Rumbaugh在通用电气发表的建模技术——Object Modeling Technique)和Booch方法。如果你觉得UML有些让你无所适从,也不必紧张,UML本身只是一个辅助工具,它的目的是帮助你描述系统,不是复杂你的工作,如果你的系统很简单,一句话可以说的很清楚,那么不要用UML,如果你只想说明类之间的关系,而不是类的接口描述,那么像第一副图那样简单的描述就很好,总之不要去追求细节,只要能说明问题,那么你的目的就达到了(甚至你没有必要完全遵守规范)。

参考书目
《设计模式——可复用面向对象软件的基础》
作者: Erich Gamma 等 译者:李英军 马晓星 蔡敏 刘建中 机械工业出版社2000

《UML参考手册》作者: James Rumbaugh Ivar Jacobson Grady Booch
译者: 姚淑珍 唐发根 机械工业出版社2001

《UML精粹——标准对象建模语言简明指南(第2版)》
作者: Martin Fowler&Kendall Scott 译者: 徐家福 清华大学出版社 2002

《Design Patterns Explained》Alan Shalloway, James R. Trott
Addison-Wesley Pub 2001

  • 35
    点赞
  • 253
    收藏
    觉得还不错? 一键收藏
  • 7
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 7
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值