设计模式与设计原则简介（开篇） 信托融资方案设计原则是什么

我们知道对于很多数学问题，经常会有多种不同的解法

而且这其中可能会有一种比较通用简便高效的方法

我们在遇到类似的问题或者同一性质的问题时，也往往采用这一种通用的解法

将话题转移到程序设计中来

对于软件开发人员， 在软件开发过程中， 面临的一般问题的解决方案就是设计模式（准确的说是OOP中）

当然，如同数学的解题思路一样，设计模式并不是公式一样的存在

设计模式（Design pattern）代表了最佳的实践

是众多软件开发人员经过相当长的一段时间的试验和错误总结出来的宝贵经验

是解决问题的思路

总之，设计模式是一种思想，思想，思想。

起源

随着面向对象编程语言的发展，以及软件开发规模的不断扩大

编写良好的OOP程序变得困难，而编写可复用的OOP程序则更是困难

在 1994 年，由 Erich Gamma、Richard Helm、Ralph Johnson 和 John Vlissides

四人合著出版了一本名为 Design Patterns - Elements of Reusable Object-Oriented Software（中文译名：设计模式 - 可复用面向对象软件的基础） 的书

该书首次提到了软件开发中设计模式的概念。

四位作者合称 GOF（四人帮，全拼 Gang of Four）

这就是设计模式四个字的起源

当然，即使在这本书出版之前，肯定也已经有很多有经验的OOP程序员已经在使用自己的经验(设计模式)了

但是这本书将OOP的设计经验作为设计模式记录下来

使我们能够更加简单方便的复用成功的设计经验和体系结构

 

设计原则

"随着面向对象编程语言的发展，以及软件开发规模的不断扩大

编写良好的OOP程序变得困难，而编写可复用的OOP程序则更是困难"

设计模式的起源， 正是需要设计模式的根本原因

借助于设计模式，可以更好地实现代码的复用，增加可维护性

 

怎么才能更好地实现代码复用呢？

面向对象有几个原则：

根本原则

 

开闭原则（Open Closed Principle，OCP）  一个软件实体应当对扩展开放，对修改关闭 。即软件实体应尽量在不修改原有代码的情况下进行扩展

 

在开闭原则的定义中，软件实体可以指一个软件模块、一个由多个类组成的局部结构或一个独立的类

不修改已有代码的基础上扩展系统的功能的形式，就是符合开闭原则的

开闭原则的关键是抽象

比如，一个方法中

if(){

//...

}else if(){

//...

}

如果新增加一个逻辑功能点，则需要增加新的else  或者 else if ，势必修改了已有代码

而如果面向抽象的接口或者抽象类进行编程，扩展增加新的功能，只需要传递新的子类即可，原有的代码功能不会有任何的修改

 

再比如

实际项目开发的时候，我们会把一些配置写入到配置文件中，而不是"硬编码"到代码中

修改参数设置的时候，源代码无需更改，这也是符合开闭原则

开闭原则作为根本原则，并不限定某种具体场景，只要是符合了这一含义，就是符合开闭原则

总之，开闭原则就是别因为新增功能扩展改(老)代码

 

 

六大原则

开闭原则是根本纲领，它是面向对象设计的终极目标

 

除了根本原则另外还有六大原则 ， 则可以看做是开闭原则的实现方法

 

单一职责原则 （Single Responsiblity Principle SRP）里氏替换原则（Liskov Substitution Principle，LSP）依赖倒转原则（Dependency Inversion Principle，DIP）接口隔离原则（Interface Segregation Principle，ISP）合成/聚合复用原则（Composite/Aggregate Reuse Principle，C/ARP）迪米特法则（Principle of Least Knowledge，PLK，也叫最小知识原则）

 

单一职责原则 （Single Responsiblity Principle SRP）

一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因

单一职责的原则很简单，就是一个实体(一个类或者一个功能模块)不要承担过多的责任

承担了过多的责任也就意味着多个功能的耦合

堆积木时， 到底是一块积木比较容易利用， 还是多块积木拼接起来的"一大块" 更容易利用? 结果显而易见 

而且，承担了过多的责任，也就是可能会因为多个原因修改这段代码

随之而来的是不稳定性以及维护成本的增加，也就是将会有多个原因引起他变化

单一职责原则的根本在于控制类的粒度大小

 

里氏替换原则（Liskov Substitution Principle，LSP）

里氏替换原则是以提出者 Barbara Liskov  的名字命名的 

定义:

如果对每一个类型为 T1的对象 o1，都有类型为 T2 的对象o2

使得以 T1定义的所有程序 P 在所有的对象 o1 都代换成 o2 时，程序 P 的行为没有发生变化

那么类型 T2 是类型 T1 的子类型

 

简单说就是 如果 一个程序P(T1) ，如果将输入T1 替换为T2 ，而且 P(T1) = P(T2)

那么T2 是T1的子类型

 

再简单的概述就是:

所有引用基类的地方必须能透明地使用其子类的对象

 

透明也就意味着不感知，不受任何影响

听起来好像很自然的就可以做到

假如子类覆盖了父类的方法呢?假如子类覆盖了父类的方法并且改变了父类方法的原有功能逻辑呢?

比如，原来传递来两个参数进行加法运算，子类覆盖后，进行减法运算，会发生什么?

里氏代换原则的根本，在软件中将一个基类对象替换成它的子类对象，程序将不会产生任何错误和异常

想要透明的使用子类，满足里氏替换原则

需要注意应该尽可能的将父类设计为抽象类或者接口

让子类继承父类或实现父接口，并实现在父类中