面向对象设计原则和23个设计模式的笔记

面向对象设计原则和23个

设计模式的笔记

面向对象三大特点：

----------------------------------

封装：

------------------

封装，也就是把客观事物封装成抽象的类，并且类可以把自己的数据和方法只让可信的类或者对象操作，对不可信的进行信息隐藏。

不关注处理过程了，只有对象和其职能。

只允许设定的对象访问自身信息，其余私人信息隐藏。

作用：封装可以隐藏实现细节，使得代码模块化，局域化，简单；

继承：

------------------

继承的父类最好是接口，最好连属性都没有。

少用实现继承（库内使用较多），多用组合。

忘了多重继承，除非实现多接口。

作用：扩展已有代码模块；代码重用（库内使用较多），多态的基础

多态：

------------------

静态--编程时采用父类型-针对接口编程

动态--执行时才实际映射成具体的子类

作用：静态时针对接口编程，执行时才体现实际的效果

面向对象设计原则：

------------------------------------

单一职责原则（SRP）：

------------------

就一个类而言，应该仅有一个引起它变化的原因；当职责越多，耦合越多，易遭破坏

软件设计真正要做的就是发现职责并将这些职责相互分离

把职责分离到单独的类中,因为每一个类都是变化的轴线，当需求变化时,该变化会反映为类的职责的变化，如果一个类承担了多余一个的职责,那么引起他变化的原因就会有多个。职责定义为“变化的原因”。

如果一个类承担的职责过多,就等于把这些职责耦合在了一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会受到意想不到的破坏。

另一方面，如果应用程序的变化方式总是导致这两个职责同时变化，那么就不必分离它们，实际分离它们就会导致不必要的复杂性的臭味。

SRP是所有原则中最简单的也是最难以正确应用的原则之一。

开放封闭原则：

------------------

软件实体应该可以扩展，但是不可修改。

软件要容易维护又不容易出问题的最好方法是多扩展，少修改。

无论模块多么封闭，都会有无法封闭的变化，事先构造抽象隔离这些变化。

面对新需求，对程序的改动是通过增加新代码进行的，而不是更改现有的代码。

OCP的关键是抽象，对于代码的改动是通过增加新代码进行的，而不是更改现有代码，因此他就不会引起像不遵循OCP原则那样的连锁改动。

通常，我们更愿意一直等到确实需要那些抽象时再把他放进去，“我们愿意被第一颗子弹射中，但是我们不会再被同一支枪射得其他子弹射中”。

可以按照以下的一些方法完成这项工作:

我们首先编写测试.测试描绘了系统的一种使用方法,通过首先编写测试,我们迫使系统成为可测试的,在一个具有可测试的.在一个具有可测试性的系统中发生变化时,我们可以坦然对之,因为我们已经构建了使用系统可测试的抽象,并且通常这些抽象中的许多都会隔离以后发生的其他种类的变化.

在许多方面,OCP都是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处(灵活,可重用,可维护性),然而,并不是说只要使用一种面向对象的语言就是遵循了这个原则,对于程序中的每个部分都肆意进行抽象同样不是一个好主意,正确的做法是,开发人员应该仅仅对程序中呈现出频繁变化的那部分作出抽象.拒绝不成熟的抽象和抽象本身一样重要.

依赖倒转原则

------------------

高层模块不应该依赖低层模块，两个都应该依赖于抽象

抽象不应该依赖于细节，细节应该依赖于抽象

即要针对接口编程，不要对实现编程

本应该是高层的策略设置模块去影响低层细节实现的模块的，包含高层业务规则的模块应该优先并独立于包含实现细节的模块，无论如何高层模块都不应该依赖于低层模块。

我们更希望能够重用的是高层策略模块，如果高层模块独立于底层模块，那么高层模块就能更容易的被重用，该原则是框架的设计核心原则。

所有结构良好的面向对象的架构都具有清晰的层次定义，每个层次通过一个定义良好的、受控制的接口向外提供一组内聚的服务。

每个较高的层次都为它所需要服务声明一个抽象接口，较低层次实现了这些抽象接口，每个高层类都通过接口使用下一层，这样高层就不依赖于低层。低层反而依赖于在高层中声明的抽象服务接口。

这种倒置不仅仅是依赖关系的倒置。它也是接口所有权的倒置。

依赖倒置可以应用于任何一个类向另一个类发送消息的地方。

违反DIP，高层策略没有和底层实现分离，抽象没有和具体细节分离，没有这种分离，高层策略

就自动的依赖于低层模块，抽象就自动的依赖于具体细节。

里氏代换原则（LSP）

------------------

子类型必须替换掉它们的父类型。

适用于父类的一定适用于子类

LSP让我们得到一个非常重要的结论:一个模型，如果孤立的看，并不具有真正意义上的有效性，

模型的有效性必须通过他的客户程序来表现。

如果一组类都支持一个公共的职责，那么它们就应该从一个公共的超类继承该职责。如果公共的

超类还不存在，那么就创建一个，并把公共的职责放入其中，毕竟这样一个类的有用性是确定无

疑的。

有一些简单的启发规则可以提供一些有关违反LSP的提示，这些规则都和以某种方式从其基类中

去除某功能的派生类有关，完成的功能少于其基类的派生类通常是不能替换其基类的，因此就违

反了LSP。

另外一种违反LSP的规则形式是在派生类的方法中添加了其基类不会抛出的异常，如果基类的使

用者不期望这些异常，那么把它们添加到派生类的方法中就会导致不可替代性，此时要遵循LSP，要么就必须改变使用者的期望，要么派生类就不应该抛出这些异常。

OCP是OOD中很多说法的核心。如果这个原则应用的有效，应用程序就会具有更多的可维护性，

可重用性以及健壮性，LSP是使用OCP成为可能的主要原则之一。

迪米特法则（LoD）

------------------

如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需

要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。

法则强调类之间的松耦合。

接口隔离原则ISP

------------------