设计模式六大原则之单一职责原则

一、什么是设计模式

设计模式:设计模式(Design pattern)是一套被反复使用、多数人知晓的、经过分类编目的、代码设计经验的总结。由此可见,设计模式不是代码复用而是经验复用。是代码设计的经验总结。

设计模式的六大原则:【单一职责、里氏替换、依赖倒置、接口隔离、迪米特法则、开闭】

23中常用的设计模式:

【单例模式、工厂模式、抽象工厂模式、模板模式、代理模式、建造者模式、原型模式、中介者模式、

命令模式、装饰模式、策略模式、责任链模式、适配模式、迭代器模式、组合模式、观察者模式、备忘录模式、

门面模式、状态模式、桥梁模式、解析器模式、享元模式、访问者模式】

二、单一职责原则简要介绍

单一职责原则:

Single Responsibility Principle,简称是SRP。SRP原则的解释是:There should never be more than one reason for a class to change。有且仅有一个原因引起类的改变。也就是一个类只负责一项职责。

单一职责原则,使类的职责明确,要扩展功能或者修改某些功能的时候,仅需修改负责该职责的类,而不用大动干戈。

下面以种花为例子。实现种植者,种红花,给红花浇浇水。种黄花,给黄花浇浇水过程。

种花的大概过程是,种植者,挖坑,种花,填土。适当的时候浇水施肥。

抽象后,类图表示如下:

代码如下:

plantStep 接口代码:种花流程

<span style="font-size:14px;">package dim.SRP.simples;

public interface PlantStep {
/**
 * 挖个坑,用来种东西
 */
	public void digHole();
	/**
	 * 种东西
	 */
	public void putPlant(Plant p );
	/**
	 * 填土
	 */
	public void coverSiol();
	/**
	 * 浇水
	 * @param Name  指定给那棵植物浇水
	 */

	public void watering();
	/**
	 * 施肥
	 * @param Name 指定给那棵植物施肥
	 */
	public void fetilizing();

	public Plant findThePlant(Plant p);
}
</span>

Planter 实现PlantStep 接口:实现之后,种植者可以调用步骤种花。

<span style="font-size:14px;">package dim.SRP.simples;

public class Planter implements PlantStep {
          Plant plant;

          public Planter( ) {
			// TODO Auto-generated constructor stub

		}
	@Override
	public void digHole() {
		// TODO Auto-generated method stub

	}

	@Override
	public void putPlant(Plant plant) {
		// TODO Auto-generated method stub
		this.plant=plant;
		System.out.println("what you planted is  "+this.plant.getName());
	}

	@Override
	public void coverSiol() {
		// TODO Auto-generated method stub

	}

	@Override
	public void watering() {
		// TODO Auto-generated method stub
		System.out.println("watering  "+this.plant.getName());
	}

	@Override
	public void fetilizing() {
		// TODO Auto-generated method stub

	}
	@Override
	public Plant findThePlant(Plant p) {
		// TODO Auto-generated method stub
		this.plant=p;
		return this.plant;
	}

}
</span>

花是植物,植物的简单接口是:

<span style="font-size:14px;">package dim.SRP.simples;

import java.awt.Color;

public interface Plant {
	/**
	 * 设置植物的名字
	 * @param Name
	 */
	public void setName(String Name);

	public String getName();
	/**
	 * 设置植物高度
	 * @param Hight
	 */
          public void setHight(float Hight);
          /**
           * 设置植物颜色
           * @param color
           */
          public void setColor(Color color);
          /**
           * 设置植物的重量
           * @param weight
           */
	      public void setWeight(int weight);

}
</span>

红花:

<span style="font-size:14px;">package dim.SRP.simples;

import java.awt.Color;

public class RedFlower implements Plant{
         private String NameOfF="";

     	@Override
    	public void setName(String Name) {
    		// TODO Auto-generated method stub
    		this.NameOfF=Name;
    	}

    	@Override
    	public String getName() {
    		// TODO Auto-generated method stub
    		return NameOfF;
    	}
	@Override
	public void setHight(float Hight) {
		// TODO Auto-generated method stub

	}

	@Override
	public void setColor(Color color) {
		// TODO Auto-generated method stub

	}

	@Override
	public void setWeight(int weight) {
		// TODO Auto-generated method stub

	}

}
</span>

黄花:

<span style="font-size:14px;">package dim.SRP.simples;

import java.awt.Color;

public class YellowFlower  implements Plant {

	String flowerName="";
	@Override
	public void setName(String Name) {
		// TODO Auto-generated method stub
		flowerName=Name;
	}

	@Override
	public String getName() {
		// TODO Auto-generated method stub
		return flowerName;
	}

	@Override
	public void setHight(float Hight) {
		// TODO Auto-generated method stub

	}

	@Override
	public void setColor(Color color) {
		// TODO Auto-generated method stub

	}

	@Override
	public void setWeight(int weight) {
		// TODO Auto-generated method stub

	}

}
</span>

测试类:

<span style="font-size:14px;">package dim.SRP.simples;

public class TestPlantClass {

	public  static  void main(String[] args) {
		RedFlower redFlower=new RedFlower();
		redFlower.setName("red flower");

		Planter planter=new Planter();
		//种红花,然后浇浇水。
		planter.digHole();
		planter.putPlant(redFlower);
		planter.coverSiol();
		planter.watering();

		YellowFlower yellowFlower=new YellowFlower();
		yellowFlower.setName("Yellow flower");
		//种黄花,然后浇浇水
		planter.findThePlant(yellowFlower);
		planter.digHole();
		planter.putPlant(yellowFlower);
		planter.coverSiol();
		planter.watering();
		//指定给红花浇水
		planter.findThePlant(redFlower);
		planter.watering();
	}
}</span>

打印结果:

what you planted is  red flower

watering  red flower

what you planted is  Yellow flower

watering  Yellow flower

watering  red flower

看来运行对了,但是这个抽象有很多问题,需要进一步向上抽象。比如,种植者当中,不是每个人都是种花浇水。应该是有的种花,有的浇水。而且花种完了,不用再种,只剩下浇水,施肥等。得想办法抽象出一个浇水施肥的种植者CarePlanter。

抽象类图如下:

上面的施肥浇水种植者,职责单一,负责花的照料工作。同样,要其他的裁剪花草,采摘果子的可以一一拓展。

SRP原则:有且仅有一个原因引起类的改变。也就是一个类只负责一项职责。

参考资料:

《设计模式之禅》

《HeadFirst》

《StartUML详解》

设计模式六大原则

时间: 2024-08-04 09:34:03

设计模式六大原则之单一职责原则的相关文章

学习设计模式 - 六大基本原则之单一职责原则

设计模式总共有六大基本原则,统称为SOLID (稳定)原则,分别是S-单一职责原则(Single Responsibility Principle), O-开闭原则(Open closed Principle),L-里氏替换原则(Liskov Substitution Principle),L-迪米特法则(Law of Demeter),I-接口隔离原则(Interface Segregation Principle),D-依赖倒置原则(Dependence Invension Principl

面向对象编程6大设计原则:单一职责原则

单一职责原则(Single  Responsibility Principle)简称SRP原则. 定义 应该有且仅有一个原因引起类的变更. 优点 可以降低类的复杂度,一个类只负责一项职责,其逻辑肯定要比负责多项职责简单的多: 提高类的可读性,提高系统的可维护性: 变更引起的风险降低,变更是必然的,如果单一职责原则遵守的好,当修改一个功能时,可以显著降低对其他功能的影响. 说明 单一职责原则不只是面向对象编程思想所特有的,只要是模块化的程序设计,都适用单一职责原则: 单一职责原则要根据项目的实际情

面向对象设计原则:单一职责原则(The Single Responsibility Principle)

热爱生活.享受娱乐.专注技术,欢迎关注微信公众号QGer,我们一起见证成长! 什么是单一职责原则? - 官方解释:一个类应该只有一种改变的原因 - 通俗解释:一个类被修改.拓展的时候,应该只能因为一种职责(功能)的扩展,而不应该有第二种职责导致类的修改,一个也不能有另一种职责存在. 为什么遵循单一职责原则? 降低类的复杂度,一个类负责一种职责,逻辑上也变得直观简单. 使代码变得灵活,提高系统的维护性. 变更的风险降低,有需求就会有变更,单一职责原则可降低变更的影响面. 保持松耦合,提供内聚. 如

设计模式(三)面向对象设计原则之单一职责原则

引用自:http://blog.csdn.net/lovelion  作者:刘伟 单一职责原则是最简单的面向对象设计原则,它用于控制类的粒度大小.单一职责原则定义如下: 单一职责原则(Single Responsibility Principle, SRP):一个类只负责一个功能领域中的相应职责, 或者可以定义为:就一个类而言,应该只有一个引起它变化的原因. 单一职责原则告诉我们:一个类不能太"累"!在软件系统中,一个类(大到模块,小到方法)承担的 职责越多,它被复用的可能性就越小,而

面向对象五大原则_1.单一职责原则&amp;amp;2.里氏替换原则

单一职责原则:Single Responsibility Principle (SRP) 一个类.仅仅有一个引起它变化的原因.应该仅仅有一个职责.每个职责都是变化的一个轴线.假设一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其他的职责.另外,多个职责耦合在一起,会影响复用性. 比如:要实现逻辑和界面的分离. T负责两个不同的职责:职责P1.职责P2.当因为职责P1需求发生改变而须要改动类T时.有可能会导致原本执行正常的职责P2功能发生问题.

day01_面向对象五大原则_1.单一职责原则&amp;2.里氏替换原则

单一职责原则:Single Responsibility Principle (SRP) 一个类,只有一个引起它变化的原因.应该只有一个职责.每一个职责都是变化的一个轴线,如果一个类有一个以上的职责,这些职责就耦合在了一起.这会导致脆弱的设计.当一个职责发生变化时,可能会影响其它的职责.另外,多个职责耦合在一起,会影响复用性.例如:要实现逻辑和界面的分离. T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常的职责P2功能发生故障.也就是

设计原则之单一职责原则

定义:一个类只负责一项职责,应该只有一个能引起它变化的原因. 问题:类T负责两个不同的职责:职责P1,职责P2.当由于职责P1需求发生改变而需要修改类T时,有可能会导致原本运行正常 的职责P2功能发生故障. 解决:分别建立两个类T1.T2,使T1完成职责P1功能,T2完成职责P2功能.这样,当修改类T1时,不会使职责P2发生故障风险: 同理,当修改T2时,也不会使职责P1发生故障风险. 举个栗子:介绍几种动物的栖息地和食物,这里边有两项职责:栖息地和食物. 用一个类Recommend介绍牛生活在

6大设计原则(1):单一职责原则

定义:应该且仅有一个原因引起类的变更. 理解: 如果一个类承担的职责过多,就等于把这些职责耦合在一起,一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力, 这种耦合会导致脆弱的设计.当变化发生时,设计会遭受到意想不到的破坏. 假如一个类A,有两个职责a,b,当职责a由于需求发生变化而需要修改时,有可能会导致职责b的功能发生故障. 解决: 将类中的职责分开,分别建立两个类. 如果是面向接口编程的话,就是将两个职责抽象成为两个不同的接口,原接口再实现这两个接口. 单一职责原则的好处: 1.类的

面向对象设计原则之单一职责原则(SRP)

Web程序猿博客:http://blog.csdn.net/thinkercode 这条原则曾经在 Tom DeMaro 和 Meilir Page-Jones 的著作中描述过,并称之为内聚性(cohesion).他们把内聚性定义为:一个模块的组成元素之间的功能相关性. 单一职责原则(SRP) 单一职责原则(Single Responsibility Principle, SRP):就一个类而言,应该仅有一个引起它变化的原因. 单一职责的原则告诉我们:在软件系统中,如果一个类承担的职责过多,就等