软件设计六大原则

OOP遵照：依赖倒置原则(DIP)

依赖倒置（Dependence Inversion Principle）原则讲的是：要依赖于抽象，不要依赖于具体。

简单的说，依赖倒置原则要求客户端依赖于抽象耦合。原则表述：phpma开源 罗江游鱼

抽象不应当依赖于细节；细节应当依赖于抽象；
要针对接口编程，不针对实现编程。

反面例子：

 

缺点：耦合太紧密，Light发生变化将影响ToggleSwitch。

解决办法一：
将Light作成Abstract，然后具体类继承自Light。
 

优点：ToggleSwitch依赖于抽象类Light，具有更高的稳定性，而BulbLight与TubeLight继承自Light，可以根据"开放－封闭"原则进行扩展。只要Light不发生变化，BulbLight与TubeLight的变化就不会波及ToggleSwitch。

缺点：如果用ToggleSwitch控制一台电视就很困难了。总不能让TV继承自Light吧。

解决方法二：
 

优点：更为通用、更为稳定。

结论：

使用传统过程化程序设计所创建的依赖关系，策略依赖于细节，这是糟糕的，因为策略受到细节改变的影响。依赖倒置原则使细节和策略都依赖于抽象，抽象的稳定性决定了系统的稳定性。

里氏替换原则(Liskov Substitution Principel)是解决继承带来的问题。

 

继承的优点：

• 代码共享，减少创建类的工作量，每个子类都拥有父类的方法和属性；
• 提高代码的重用性；
• 子类可以形似父类，但又异于父类；
• 提高代码的可扩展性；
• 提高产品或项目的开放性。

继承的缺点：

• 继承是侵入性的，只要继承就必须拥有父类的所有属性和方法；
• 降低代码的灵活性，子类必须拥有父类的属性和方法，让子类增加了约束；
• 增强了耦合性，当父类的常量、变量和方法被修改时，必须考虑子类的修改。  

定义：

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

通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道是父类还是子类。但是，反过来就不行了，有子类出现的地方，父类未必就能适应。

 

含义：

• 子类必须完全实现父类的方法

在类中调用其他类时务必要使用父类或接口，如果不能使用父类或接口，则说明类的设计已经违背了里氏替换原则。

如果子类不能完整地实现父类的方法，或者父类的某些方法在子类中发生了“畸变”，则建议断开父子继承关系，采用依赖、聚集、组合等关系代替继承。 

• 子类可以有自己的个性  
• 覆盖或实现父类的方法时输入参数可以被放大

如果子类的前置条件较小，子类在没有覆写父类的方法的前提下，子类方法被执行了，这会引起业务逻辑混乱，因为在实际应用中父类一般都是抽象类，子类是实现类，你传递一个这样的实现类就会“歪曲”了父类的意图，引起一堆意想不到的业务逻辑混乱。 

• 覆盖或实现父类的方法时输出结果可以被缩小  

目的：

采用里氏替换原则的目的就是增强程序的健壮性，版本升级是也可以保持非常好的兼容性。即使增加子类，原有的子类还可以继续运行。在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑。

设计模式之六大原则——单一职责原则(SRP)

定义：

应该有且仅有一个原因引起类的变更。

There should never be more than one reason for a class to change.

 

优点：

1、类的复杂性降低，实现什么职责都有清晰明确的定义；

2、可读性提高，复杂性减低，可读性当然提高；

3、可维护性提高，可读性提高，可维护性当然提高；

4、变更引起的风险减低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的类有影响，对其他接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

 

注意：

单一职责原则提出了一个编写程序的标准，用“职责”或“变化原因”来衡量接口或类设计得是否优良，但是“职责”和“变化原因”都是不可度量的，因项目而异，因环境而异。

 

建议：

接口一定要做到单一职责，类的设计尽量做到只有一个原因引起变化。

设计模式之六大原则——接口隔离原则（ISP）

接口隔离原则 Interface Segregation Principle 

定义：

• 客户端不应该依赖它不需要的接口
• 类间的依赖关系应该建立在最小的接口上

我们可以把这两个定义概括为一句话：建立单一接口，不要建立臃肿庞大的接口。再通俗一点讲：接口尽量细化，同时接口中的方法尽量少。

提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有的客户端访问。

 

接口是我们设计时对外提供的契约，通过分散定义多个接口，可以预防未来变更的扩散，提高系统的灵活性和可维护性。

 

含义：

• 接口要尽量小

这是接口隔离原则的核心定义，不出现臃肿的接口（Fat Interface），但是“小”是有限度的，首先就是不能违反单一职责原则。

根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

• 接口要高内聚

高内聚就是要提高接口、类、模块的处理能力，减少对外的交互。

具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺地越少对系统开发越有利，变更的风险也就越少，同时也有利于降低成本。

• 定制服务

定制服务就是单独为一个个体提供优良的服务。

• 接口设计是有限度的

接口的设计粒度越小，系统越灵活，这是不争的事实。但是，灵活的同时也带来了结构的复杂化，开发难度增加，可维护性降低，这不是一个项目或产品所期望看到的，所以接口设计一定要注意适度，这个度只能根据经验和常识判断，没有一个固化或可测量的标准。

设计模式之六大原则——迪米特法则（LoD，LKP）



定义：

迪米特法则（Law of Demeter，LoD）也称为最少知识原则（Least Knowledge Principle，LKP）。

一个对象应该对其他对象有最少的了解。通俗地讲，一个类应该对自己需要耦合或调用的类知道得最少，你（被耦合或调用的类）的内部是如何复杂都和我没关系，那是你的事情，我就知道你提供的public方法，我就调用这么多，其他的一概不关心。

 

含义：

• 只和朋友交流

朋友类的定义是这样的：出现在成员变量、方法的输入输出参数中的类称为成员朋友类，而出现在方法体内部的类不属于朋友类。

 

下面的代码在方法体内部依赖了其他类，这严重违反迪米特法则

view source print ?

01	public class Teacher {

02

03	publicvoid commond(GroupLeader groupLeader) {

04	List<Girl> listGirls =new ArrayList<Girl>();

05

06	for(int i = 0; i < 20; i++) {

07	listGirls.add(newGirl());

08

}

09

10	groupLeader.countGirls(listGirls);

11

}

12

13

}

方法是类的一个行为，类竟然不知道自己的行为与其他类产生了依赖关系，这是不允许的。

正确的做法是：

view source print ?

1	public class Teacher {

2

3	publicvoid commond(GroupLeader groupLeader) {

4	groupLeader.countGirls();

5

}

6

7

}

view source print ?

01	public class GroupLeader {

02

03	privateList<Girl> listGirls;

04

05	publicGroupLeader(List<Girl> _listGirls) {

06	this.listGirls = _listGirls;

07

}

08

09	publicvoid countGirls() {

10	System.out.println("女生数量是："+ listGirls.size());

11

}

12

13

}

注意：一个类只和朋友交流，不与陌生类交流，不要出现getA().getB().getC().getD()这种情况（在一种极端情况下允许出现这种访问，即每一个点号后面的返回类型都相同），类与类之间的关系是建立在类间的，而不是方法间，因此一个方法尽量不引入一个类中不存在的对象，当然，JDK API提供的类除外。

• 朋友间也是有距离的

一个类公开的public属性或方法越多，修改时涉及的面也就越大，变更引起的风险扩散也就越大。因此，为了保持朋友类间的距离，在设计时需要反复衡量：是否还可以再减少public方法和属性，是否可以修改为private、package-private（包类型，在类、方法、变量前不加访问权限，则默认为包类型）、protected等访问权限，是否可以加上final关键字等。

注意：迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。

 

• 是自己的就是自己的

如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，就放置在本类中。

 

• 谨慎使用Serializable

 

最后，迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高

设计模式之六大原则——开闭原则（OCP）

开闭原则（Open Closed Principle）是Java世界里最基础的设计原则，它指导我们如何建立一个稳定的、灵活的系统。

 

定义：

一个软件实体如类、模块和函数应该对扩展开放，对修改关闭。

Softeware entities like classes,modules and functions should be open for extension but closed for modifications.

 

开闭原则的含义是说一个软件实体应该通过扩展来实现变化，而不是通过修改已有代码来实现变化。

软件实体包括以下几个部分：

• 项目或软件产品中按照一定的逻辑规则划分的模块
• 抽象和类
• 方法

开闭原则是为软件实体的未来事物而制定的对现行开发设计进行约束的一个原则。

 

注意：开闭原则对扩展开放，对修改关闭，并不意味着不做任何修改，低层模块的变更，必然要有高层模块进行耦合，否则就是一个孤立无意义的代码片段了。

 

变化的类型：

• 逻辑变化
• 子模块变化
• 可见试图变化

一个项目的基本路径应该是这样的：项目开发、重构、测试、投产、运维，其中的重构可以对原有的设计和代码进行修改，运维尽量减少对原有代码修改，保持历史代码的纯洁性，提高系统的稳定性。

 

开闭原则的重要性：

• 开闭原则对测试的影响

开闭原则可是保持原有的测试代码仍然能够正常运行，我们只需要对扩展的代码进行测试就可以了。

• 开闭原则可以提高复用性

在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用，粒度越小，被复用的可能性就越大。

• 开闭原则可以提高可维护性
• 面向对象开发的要求

 

如何使用开闭原则：

• 抽象约束

第一，通过接口或者抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；

第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；

第三，抽象层尽量保持稳定，一旦确定即不允许修改。

• 元数据（metadata）控制模块行为

元数据就是用来描述环境和数据的数据，通俗地说就是配置参数，参数可以从文件中获得，也可以从数据库中获得。

Spring容器就是一个典型的元数据控制模块行为的例子，其中达到极致的就是控制反转（Inversion of Control）

• 制定项目章程

在一个团队中，建立项目章程是非常重要的，因为章程中指定了所有人员都必须遵守的约定，对项目来说，约定优于配置。

• 封装变化

对变化的封装包含两层含义：

第一，将相同的变化封装到一个接口或者抽象类中；

第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或抽象类中。