本文中会介绍一些笔者对于面向对象设计概念学习的笔记、理解以及实现思路。希望这些内容能够帮助大家对面向对象设计这一概念有更多的认识。若文中有错误的理解和概念,请大家及时纠正;吸纳大家的建议,对于我来说也是很重要的学习过程之一。

1.基本概念

由于对象是对事物的理解和抽象,所以对象就是对一个事物的属性和行为的理解和抽象。正是这样的一种关系,面向对象就是对一个事物的属性和行为的理解和抽象的方法。理解对象以及抽象“对象”就是在理解和抽象事物的属性和行为。
在使用面向对象进行分析、设计、编码的时候,首先应该想到的是属性和方法组合形成的对象。

2.对象种类

  • 基于章节1中的介绍,抽象出的对象一般会有如下几种形式:

    1.属性和方法组合形成的对象

    2.只包含属性的对象

    3.只包含方法的对象

3.抽象原则

  • 集合章节1与章节2中针对对象的基本概念与分类后,其相应的抽象方法就显而易见了:

    1.当你需要抽象一个事物的事情和物体时就需要属性和方法的组合

    2.当你只需要抽象一个事物的物体时就只需要属性

    3.当你只需要抽象一个事物的事情时就只需要方法

4.对象建模(OOA)和数据库建模的区别

在数据库系统中,它们关心的是事物中的物体,所以在抽象事物时它们只抽象了事物中的属性(即表结构,但没有抽象数据库操作)。只要需要抽象事物(事情和物体)中的属性,一般都是可能需要持久化;而需要持久化的情况,通常又是保存到关系型数据库中,在关系型数据库中的表(Table)基本上是与面向对象中的对象(Object)的属性是一一对应的。使用数据库建模,有可能会导致上层服务中会混进业务逻辑。
使用对象建模就可以实现将业务逻辑封装到对应的对象中,上层逻辑中只用来实现执行流程。这是一种不再包含业务逻辑的服务对象,而这些上层逻辑(服务)称为应用服务(Application Service)。

  • 这两种建模方式各自的特点为:

    采用数据模型建模配合业务逻辑服务的方式更像是过程化编程,只是在使用面向对象语言来编写过程化代码。

    采用对象模型配合应用服务的方式才是符合面向对象编程

对于这一点,笔者的认为在以往软件工程中的设计阶段内,通常都是先设计数据库表结构(ER关系),之后依照数据库结构编写DAO层,业务逻辑层以及展现层。而对象建模的流程恰恰与其相反对象建模是先对业务需求进行抽象,之后利用对象的实例方法来编写业务层服务(业务逻辑),同时针对对象的属性设计数据库表结构,实现数据持久化。因此,在使用面向对象设计理念去设计工程架构时,一定不能套用原有的设计思路在实现。

5.面向对象中的组合与聚合

组合与聚合在面向对象中是相当重要的。组合与聚合是在探讨整体与部分的关系,这种整体与部分的关系是一种比关联关系更强的关系。比如:汽车与轮胎,汽车是一个整体,轮胎是汽车的一部分。如果汽车没有轮胎,那么就无法构成汽车的完整性,所以在讨论整体与部分的关系时,要特别注意整体对部分的依赖性而不是部分对整体的依赖
使用组合和聚合的前提: 需要先抽象出整体对象和多个部分对象。其中,部分对象是整体对象的一部分。同时,两者是有依赖关系的,部分对象脱离整体对象后是无法独立工作的,即部分对象是依附于整体对象

  • 那么,组合和聚合定义即为:

    部分对象的创建、存在和消亡都是和整体对象一起的就称为组合。

    可以在初始化之后能够更换的或者不需要强制完整的整体与部分的关系称之为聚合。

聚合与组合的区别在于,聚合中的对象之间的依赖关系并没有组合那么强

后记

笔者认为,在面向对象设计中,组合与聚合应尽量代替继承。因为继承可以理解为一种强耦合的关系,因此不利于代码的解耦。而组合与聚合就解决了该问题,整体对象可以通过更换同类型的部分对象来继续完成相关逻辑,即两者关系为弱耦合。这对于扩展或修改整体对象的代码带来了极大的便利性和稳定性。

其次,这里之所以将组合和聚合在同一个章节来讲解,是因为这两个概念在面向对象设计中很容易混淆。就像上文所说,判断类与类之间的关系是否为聚合或组合,关键是要看其部分对象的性质:若部分对象的初始化以及回收都在整体对象中实现,则两者关系为组合关系;若部分对象的初始化不在整体对象中进行(依赖注入),即整体对象可以通过更换同类型的部分对象来使用,则两者关系为聚合关系。