设计模式6大原则:单一职责原则

前端之家收集整理的这篇文章主要介绍了设计模式6大原则:单一职责原则前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。


单一职责原则(Single Responsibility Principle),简称SRP。

定义:

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

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

有时候,开发人员设计接口的时候会有些问题,比如用户属性用户的行为被放在一个接口中声明。这就造成了业务对象和业务逻辑被放在了一起,这样就造成了这个接口有两种职责,接口职责不明确,按照SRP的定义就违背了接口的单一职责原则了。

下面是个例子:

 
 
  1. packagecom.loulijun.chapter1;
  2. publicinterfaceItutu{
  3. //身高
  4. voidsetShengao(doubleheight);
  5. doublegetShengao();
  6. //体重
  7. voidsetTizhong(doubleweight);
  8. doublegetTizhong();
  9. //吃饭
  10. booleanchiFan(booleanhungry);
  11. //上网
  12. booleanshangWang(booleansilly);
  13. }

上面的例子就存在这个问题,身高、体重属于业务对象,与之相应的方法主要负责用户属性。而吃饭、上网是相应的业务逻辑,主要负责用户的行为。但是这就会给人一种不知道这个接口到底是做什么的感觉,职责不清晰,后期维护的时候也会造成各种各样的问题。

解决办法:单一职责原则,将这个接口分解成两个职责不同的接口即可

ItutuBO.java:负责tutu(涂涂,假如是个人名)的属性

packagecom.loulijun.chapter1; 
  
  
  • /**
  • *BO:BussinessObject,业务对象
  • *负责用户属性
  • *@authorAdministrator
  • *
  • */
  • interfaceItutuBO{
  • doublegetTizhong();
  • }
  • ItutuBL.java:负责涂涂的行为

    packagecom.loulijun.chapter1; 
      
      
  • /**
  • *BL:BusinessLogic,业务逻辑
  • *负责用户的行为
  • *@authorAdministrator
  • *
  • */
  • interfaceItutuBL{
  • //吃饭
  • booleanhungry);
  • //上网
  • booleansilly);
  • }
  • 这样就实现了接口的单一职责。那么实现接口的时候,就需要有两个不同的类

    TutuBO.java

    classTutuBOimplementsItutuBO{ 
      
      
  • privatedoubleheight;
  • doubleweight;
  • @Override
  • doublegetShengao(){
  • returnheight;
  • }
  • @Override
  • doublegetTizhong(){
  • returnweight;
  • }
  • doubleheight){
  • this.height=height;
  • }
  • doubleweight){
  • this.weight=weight;
  • }
  • }
  • TutuBL.java

    classTutuBLimplementsItutuBL{ 
      
      
  • booleanhungry){
  • if(hungry)
  • {
  • System.out.println("去吃火锅...");
  • returntrue;
  • }
  • false;
  • }
  • booleansilly){
  • if(silly)
  • {
  • System.out.println("好无聊啊,上会网...");
  • false;
  • }
  • }
  • 这样就清晰了,当需要修改用户属性的时候只需要对ItutuBO这个接口来修改,只会影响到TutuBO这个类,不会影响其他类。

    那么单一职责原则的意义何在呢?

    1. 降低类的复杂性,实现什么样的职责都有清晰的定义
    2. 提高可读性
    3. 提高可维护性
    4. 降低变更引起的风险,对系统扩展性和维护性很有帮助

    但是、使用单一职责原则有一个问题,“职责”没有一个明确的划分标准,如果把职责划分的太细的话会导致接口和实现类的数量剧增,反而提高了复杂度,降低了代码的可维护性。所以使用这个职责的时候还要具体情况具体分析。建议就是接口一定要采用单一职责原则,实现类的设计上尽可能做到单一职责原则,最好是一个原因引起一个类的变化。

    原文链接:https://www.f2er.com/javaschema/286624.html

    猜你在找的设计模式相关文章