面向对象设计原则

面向对象设计原则第一页，共二十八页，2022年，8月28日内容提要面向过程设计和面向对象设计的区别面向对象设计和面向对象分析的区别面向对象设计的5条原则第二页，共二十八页，2022年，8月28日计算机语言的发展机器语言汇编语言高级语言面向对象语言计算机语言的发展方向是为了人类能够更好的理解。第三页，共二十八页，2022年，8月28日面向过程设计思想和面向对象设计思想我要去广场面向过程：我上车，我挂挡，我踩油门，我过昌北，我过八一桥….我到广场面向对象：我命令车去广场车是怎么走的我不用知道车相当于一个黑盒，所有的信息都封装在车这个类里面我不用去了解车是如何工作运行的第四页，共二十八页，2022年，8月28日面向过程设计思想和面向对象设计思想面向过程设计和面向对象设计所关注的层面不同，或者说两者的复用层面不同。面向过程设计关注的是方法，在方法层面上进行复用。面向对象设计则是隐藏了类的方法和细节，直接在对象层面上进行复用。第五页，共二十八页，2022年，8月28日面向对象设计(OOD)和面向对象分析(OOA)OOA偏重于理解问题，描述软件要做什么，而OOD偏重于理解解决方案，描述软件要如何做。OOA只考虑理想的设计，不关心技术与实现底层的细节，而OOD需要得到更具体详细更接近于现实的代码的设计方案。在设计结果的描述上，OOA偏重于描述对象的行为，OOD偏重于描述对象的属性与方法。第六页，共二十八页，2022年，8月28日面向对象分析(OOA)的主要任务

根据用户需求，建立一个准确的、完整的、一致的系统模型。该过程产生三个分析模型：功能模型：把用户的功能性需求转化为开发人员和用户都能理解的一种表达方式，其结果就是用例模型。对象模型：通过对用例模型的分析，把系统分解成互相协作的分析类。一般情况下，我们通过类图和对象图来描述系统中所有对象、对象属性、及对象之间的相互关系。对象模型就是系统的静态模型。动态模型：描述系统的动态行为，一般用顺序图和协作图来描述系统中对象之间的交互关系。第七页，共二十八页，2022年，8月28日面向对象设计的主要任务细化重组类细化和实现类间关系,明确其可见性增加属性,指定属性的类型与可见性分配职责,定义执行每个职责的方法对消息驱动的系统,明确消息传递方式利用设计模式进行局部设计画出详细的类图与时序图

第八页，共二十八页，2022年，8月28日面向对象设计同样一块布，不同的裁缝可以做出不同的衣服，相同款式的衣服，做工也有好坏之分；同样是发动机，由于设计的不同，所带来的功率和油耗也会有高有低。在面向对象设计中，如何通过很小的设计改变就可以提高系统性能或应对更多设计需求的变化，这是令设计者极为关注的问题。

第九页，共二十八页，2022年，8月28日例题分析现欲对某公司的工作人员建立一个系统的分类管理方式，该公司员工有软件员工和硬件员工两种，按工作种类分有全职员工和兼职员工。试画出一个可以表示这种关系的分类方法。第十页，共二十八页，2022年，8月28日第十一页，共二十八页，2022年，8月28日OO的设计原则单一职责原则（SingleResponsiblityPrinciple，SRP）

开闭原则（Open/ClosePrincipleOCP）Liskov替换原则（LiskovSubstitutionPrinciple，LSP）依赖倒置原则（DependencyInversionPrinciple，DIP）接口分离原则（InterfaceSegregationPrinciple，ISP）第十二页，共二十八页，2022年，8月28日单一职责原则(SRP)软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。就一个类而言，应该仅有一个引起它变化的原因。合适的行为应该出现在合适的类里。第十三页，共二十八页，2022年，8月28日开闭原则(OCP)一个模块在扩展性方面应该是开放的，而在更改性方面应该是封闭的。设计模块的时候，应尽量使模块可扩展，且扩展时不需要对模块的源代码进行修改。

第十四页，共二十八页，2022年，8月28日思考：

下图是一个针对不同打印机实现打印功能的类图设计，根据图中设计，如果现在需要添加一台Legend打印机，需做哪些修改？

上图设计并不合理，因为如果需要新加一台新的Legend打印机的话，不但要增加一个新的Legend类，还要修改Output类的内部结构。不符合开闭原则。

那么，应该如何改进呢？第十五页，共二十八页，2022年，8月28日上图中引入了一个接口类Printer，其中有一个print（）方法。Output类只与这个接口类相关联，在Output类中有一个类型为Printer的变量p。不管系统与哪种打印机连接，实现打印功能时一律调用p.print()方法。而p的具体类型在运行是由系统确定，可能是HP类型的对象，也可能是Canon类型的对象。现在如果系统需要加入Legend打印机，只需增加一个Legend类，并在该类中实现Printer接口即可。因此，上图具有良好的可扩展性，符合开闭原则。第十六页，共二十八页，2022年，8月28日Liskov替换原则(LSP)

子类可以替换父类出现在父类能出现的任何地方。

如图：ClassA要使用ClassB，ClassC是ClassB的子类。运行时，用ClassC代替ClassB，ClassA仍然可以使用原来ClassB中提供的方法，而不需要做任何改动。

设计时应把ClassB设计为抽象类或接口，让ClassC继承抽象类或实现接口。第十七页，共二十八页，2022年，8月28日例

根据鱼的种类，可以把鱼分为食肉的鱼和不食肉的鱼两种。其类图可表示如下：问题来了，为了更好的区分鱼类，现在需要新添加一种分类方法，按照可上岸不可上岸来区分。该怎么办？？鳄鱼是可以上岸的，让鳄鱼继承可上岸鱼。鳄鱼可以替换父类，完成可上岸鱼的所有行为。但是我们知道，鳄鱼也是食肉的，所以如果要让鳄鱼可以完成吃肉这个行为，必须在鳄鱼类里面定义一个吃肉方法。而这个方法已经在食肉鱼类里面做过定义了。产生了代码重复。第十八页，共二十八页，2022年，8月28日面向对象面向对象关注的是对象的行为，面向对象是使用行为来对对象进行分类的！在面向对象中子类能够替换父类（替换原则），是因为子类具有父类所有的属性和方法，同时子类还具有自己特有的元素。第十九页，共二十八页，2022年，8月28日那么到底该怎么办呢？把对象的行为表示为接口。针对每一个具体的对象，只需让该对象实现所需要的接口。public

interface

食肉

{

}

public

interface

可上岸

{

}

publicinterfaceXXX{}

public

class

Crocodile

implements

食肉，可上岸，XXX

{

}第二十页，共二十八页，2022年，8月28日依赖倒置原则(DIP)–高层模块不应该依赖于低层模块，二者都应该依赖于抽象。–抽象不应该依赖于实现细节，实现细节应该依赖于抽象。依赖倒置原则指依赖关系应该是尽量依赖接口或抽象类，而不是依赖于具体类。

第二十一页，共二十八页，2022年，8月28日依赖倒置原则(DIP)越是低级的模块，越和具体细节有关，越高层的则越抽象，但高层的模块往往是通过调用低层模块来实现的。也就是说，抽象的模块要依赖于与具体实现有关的模块，显然这是一种不好的依赖关系。在结构化设计中（如下图），高层的模块依赖于低层的模块。第二十二页，共二十八页，2022年，8月28日依赖倒置原则(DIP)

在面向对象设计中，高层的类往往与业务有关，这些类只依赖于一些抽象的类或者接口，而与具体实现有关的类，也只与抽象类和接口有关联。当具体实现的细节改变的时候，不会对高层的类产生影响。

例如下图的设计：

第二十三页，共二十八页，2022年，8月28日接口分离原则

接口分离原则指的是在设计时采用多个与特定客户类有关的接口比采用一个通用接口更好。也就是说一个类如果要被多个客户类使用，那么可以给每一个客户类创建一个接口，同时这个类能够实现所有接口。而不要一个接口中包含了所有客户类需要的方法。

第二十四页，共二十八页，2022年，8月28日下图设计是否合理？如上图所示结构，如果Service接口中针对ClientA类的方法methodA()需要改变或者需要新添加一个methodD()那么ClientB和C都可能会受到影响，因此需要进行重新编译和发布。第二十五页，共二十八页，2022年，8月28日接口分离原则

设计接口的一个基本原则就是：只实现单一的功能。接口代表一种功能，接口实现的功能太多了，就会引起严重的耦合，这是一个设计上的大忌。

上面例子应该如何修改以符合接口分离原则？

第二十六页，共二十八页，2022年，8月28日OO设计中的一些其他设计原则不同的类中相似方法的名字应该相同。遵守已有的约定或习惯，以及开发机构规定的命名方法。尽量减少消息模式的数目。只要可能，就要让消息具有一致的模式。例如，不要在一个消息中，第一个参数表示发送者的ip地址，而在另一个消息中，第一个参数表示接收者的ip。类的设计要尽可能简单，易于理解。类的泛化不宜太深。类之间的泛化一定程度上增加了类之间的耦合，除非特殊情况，否则不要设计很深层次的泛化关系。定义简单的方法。一个类的方法不应太复杂。如果一个方法太大，则可以尝试对其进行细分。第二十七页，共二十八页，2022年，8月28日思考题图