"围观"设计模式(6)--开闭原则(Open/Closed Principle)

在面向对象编程领域中,开闭原则规定“软件中的对象(类,模块,函数等等)应该对于扩展是开放的,但是对于修改是封闭的”,这意味着一个实体是允许在不改变它的源代码的前提下变更它的行为。该特性在产品化的环境中是特别有价值的,在这种环境中,改变源代码需要代码审查,单元测试以及诸如此类的用以确保产品使用质量的过程。遵循这种原则的代码在扩展时并不发生改变,因此无需上述的过程。

开闭原则的命名被应用在两种方式上。这两种方式都使用了继承来解决明显的困境,但是它们的目的,技术以及结果是不同的。----WIKIPEDIA

个人对于开闭原则的理解:

开闭原则相当于一个纲领性质的原则,提倡类等应该在设计完成后通过扩展的方式适应新的业务需求,而不是通过修改的方式去适应新的需求,这样的设计更加灵活、稳定。之前的五大原则是开闭原则思想的具体实现的情况。

归纳总结:

1. 单一职责原则是从类的功能的角度去设计,将不同的职责分别归于不同的类中,这样使得设计更加清晰、易修改。

2. 里氏替换原则是从类的继承的角度去设计,强调父类被子类继承后,在父类出现的地方,可以替换为其子类,而且行为不会发生变化。

3. 依赖倒置原则是从类之间依赖关系的角度去设计,强调高层不依赖于低层,低层依赖于高层,减少实现细节的依赖。

4. 接口隔离原则是从接口的方法设计角度去思考,强调不能过度设计接口,尽量使得接口内的方法能充分的提供给其实现类需要的功能,不要过度设计导致方法的冗余,也不要设计不充分导致,实现类中有未能抽取的公共部分。

5. 迪米特法则或最少知识原则,从类与类之间耦合的角度去思考,降低耦合,减少不必要的耦合,不要跨越多层去调用方法,最佳的方式是只调用其朋友类的方法,之后行为由朋友类负责实施。

源代码我会同步放于GitHub上,需要的朋友可以进行关注下载:下载源代码

下面看这样一个例子:

理解对扩展开放,对修改关闭是什么意思。

直接上代码,类关系简单这里不再画类图

public interface Car {

	public String getCarName();

}
public class RealCar implements Car{

	private String carName;

	public RealCar() {
		super();
	}

	public RealCar(String carName) {
		super();
		this.carName = carName;
	}

	@Override
	public String getCarName() {
		return carName;
	}

}
private static List<RealCar> carList = new ArrayList<RealCar>();

	static {
		carList.add(new RealCar("HongQI"));
		carList.add(new RealCar("BYD"));
	}

	public static void main(String[] args) {
		for (RealCar car : carList) {
			System.out.println(car.getCarName());
		}
	}

假如需求变更了,需要可以查看颜色,怎么办?去修改Car接口?

NO!!不要去修改,因为你怎么知道他在别的地方有没有被用到过,一个小的项目中或许你说你知道,但是一个大项目里面,你和别人共同在做这一块东西,那就不确定了吧,那么这里按照开放关闭原则改下设计。

CarMore这个接口可以继承Car接口,那么这个接口也就拥有了Car接口中的方法了。

public interface CarMore extends Car{

	public String getColor();
}

同样的,扩展的类继承原来实现Car接口的类RealCar,这样就完成了对新的业务需求的更改。原来的程序保持原来的状态。同时也减少了因为原来的类更改而造成的测试量增大的危险。

public class RealCarMoreInfo extends RealCar{

	private String color;

	public RealCarMoreInfo() {
		super();
	}

	public RealCarMoreInfo(String carName, String color) {
		super(carName);
		this.color = color;
	}

	public String getColor() {
		return color;
	}

}

时间: 2024-11-04 14:05:41

"围观"设计模式(6)--开闭原则(Open/Closed Principle)的相关文章

设计模式六大原则(六): 开闭原则(Open Closed Principle)

定义: 一个软件实体如类.模块和函数应该对扩展开放,对修改关闭. 问题由来: 在软件的生命周期内,因为变化.升级和维护等原因需要对软件原有代码进行修改时,可能会给旧代码中引入错误,也可能会使我们不得不对整个功能进行重构,并且需要原有代码经过重新测试. 解决方案: 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化. 开闭原则是面向对象设计中最基础的设计原则,它指导我们如何建立稳定灵活的系统. 开闭原则可能是设计模式六项原则中定义最模糊的一个了,它只告诉我们

开闭原则 Open Closed Principle

开闭原则的介绍: 1) 开闭原则(Open Closed Principle)是编程中最基础.最重要的设计原则2) 一个软件实体如类,模块和函数应该对扩展开放(对提供方),对修改关闭(对使用方).用抽象构建框架,用实现扩展细节.3) 当软件需要变化时,尽量通过扩展软件实体的行为来实现变化,而不是通过修改已有的代码来实现变化.4) 编程中遵循其它原则,以及使用设计模式的目的就是遵循开闭原则. 错误示例 package com.kittenplus.principle.ocp; public cla

Java Web 设计模式之开闭原则

1.开闭原则(OCP) 遵循开闭原则设计出的模块具有两个主要特征: (1)对于扩展是开放的(Open for extension).这意味着模块的行为是可以扩展的.当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为.也就是说,我们可以改变模块的功能. (2)对于修改是关闭的(Closed for modification).对模块行为进行扩展时,不必改动模块的源代码或者二进制代码.模块的二进制可执行版本,无论是可链接的库.DLL或者.EXE文件,都无需改动. 2.通过UML

“开-闭”原则 (Open-Closed principle, OCP)

"开-闭"原则 (Open-Closed principle, OCP) 一个软件实体应当对扩展开放,对修改关闭. Software entities should be open for extension, but closed for modification. 在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展. "可变性的封装原则"从工程的角度讲解了如何实现"开-闭"原则. "可变性的封装原则"意味着两

设计模式之开闭原则

Open-Closed Principle软件设计中的“开-闭原则” 这个原则最早是由Bertrand Meyer提出,英文的原文是:Software entities should be open for extension,but closed for modification.意思是说,一个软件实体应当对扩展开放,对修改关闭.也就是说,我们在设计一个模块的时候,应当使这个模块可以在不被修改的前提下被扩展,换句话说就是,应当可以在不必修改源代码的情况下改变这个模块的行为. 满足OCP的设计给

前端用到的设计模式之开闭原则. 里氏代换原则

开闭原则,如果jQuery源码稍微了解,肯定知道它的应用了. 一个模块----函数或对象,应该凭着经验来判断, 对扩展开放,对修改关闭.------ 一般用继承实现扩展,用闭包来实现关闭. 为什么开闭原则?它跟复杂度有什么关系,? 复杂度,就是一个函数里包含的功能个数;当开闭原则不遵守时,想扩展功能,必然去原来的函数里添加代码,导致原来的函数功能增加. 里氏代换原则:是对开闭原则的补充,子类可以扩展父类,但不可改变父类. function changFangxing(height,width){

设计原则之开闭原则Open Close Principle

翻译自http://www.oodesign.com 设计原则之开闭原则 动机:一个聪明的应用设计和代码编写应该考虑到开发过程中的频繁修改代码.通常情况下,一个新功能的增加会带来很多的修改.这些修改已存在的代码应该要最小化, 总结:软件应该对扩展开发,对修改关闭.装饰器模式,观察者模式,工厂模式可以帮助我们队代码做最小的修改. Bad Example: 缺点: 1.当新的shape被添加,开发者要花大量时间去理解GraphicEditor源码.. 2.添加新shape也许会影响已经存在的功能 /

设计模式SOLID - 开闭原则

The Open – Closed principle have been formed by Bertrand Meyer in 1988, it can be paraphrased as: Software entities (let it be classes, modules, functions, etc.) should be open for extending and closed for modification.  This simple rule means that w

开闭原则(open-close principle)

对继承开放.对修改关闭(继承了就不能修改原来父类的方法) Open for extension Closed for modification