Java设计模式（1）-- 七大原则之【单一职责原则】

这系列博文将先讲述七大设计模式的原则，再详述23种java设计模式。

博文皆是东拼西凑而成，若有错误，还望指出。

一、设计模式的目的

在代码编写的过程中，面临着代码耦合、内聚等问题，同时优质代码应该有很好的拓展性、复用性、可靠性、可读性（规范性）。设计模式包含了面向对象编程的精髓思想，使得代码呈现出

1）高内聚（相关度比较高的部分尽可能的集中，不要分散）

2）低耦合（模块之间尽可以能把依赖的部分降低到最小）

，同时也具有更好怕的代码复用性和可读性。

二、设计模式六大原则

SOLID+迪米特法则，最后额外加了一种

1）单一职责原则（Single-Resposibility Principle）

定义：A class should have a single responsibility, where a responsibility is nothing but a reason to change.（一个类应该有一个单一的职责，其中职责是唯一改变这个类的理由。）

含义：当设计某个模块的时候，我们应该留意，一个类最多为一类任务或者功能负责，并且当且仅当这类任务或者功能需要变动时，这个类才能发生变动。这样，类就会有高内聚特性。

比如，在设计一个员工类的时候，

public class Employee{
  private String employeeId;
  private String name;
  private string address;
  private Date dateOfJoining;
  public boolean isPromotionDueThisYear(){
    //promotion logic implementation
  }
  public Double calcIncomeTaxForCurrentYear(){
    //income tax logic implementation
  }
  //Getters & Setters for all the private attributes
}

上面的Employee类在逻辑上看起来正确。它具有员工所有的属性，如employeeId，name，age，address和dateOfJoining。它甚至会告诉您该员工今年是否有资格晋升，并计算出该年度他必须支付的所得税。

但是，Employee类违反了单一责任原则。让我们看看是怎么回事 –

• 确定员工是否应于今年晋升的逻辑实际上不是员工应承担的责任。公司的人力资源部门根据公司的人力资源政策（这可能每几年更改一次）承担此责任。在人力资源政策上的任何更改，都将需要更改Employee类。
• 同样，所得税的计算也不是员工的责任。财务部门负责处理当前的税收组成，该组成可能每年都会更新。如果员工类拥有所得税计算责任，那么每当税制计算方法发生变化时，都将需要更改员工类别。
• 最后，Employee类应承担维护员工核心属性的单一责任。

那么使用单一责任原则应该怎么做呢？

首先判断员工是否晋升应该是HR的工作，所以应该分开一个类

public class HRPromotions{
  public boolean isPromotionDueThisYear(Employee emp){
    //promotion logic implementation using the employee information passed
  }
}

再者就是计算税收的财务类

public class FinITCalculations{
  public Double calcIncomeTaxForCurrentYear(Employee emp){
    //income tax logic implementation using the employee information passed
  }
}

最后是Employee的核心属性类

public class Employee{ 
  private String employeeId;
  private String name;
  private string address; 
  private Date dateOfJoining;
  //Getters & Setters for all the private attributes
}

再举一个例子，比如设计商城用户类，用户拥有优惠券，用户类这样设计

public class User {
    private String id;
    private String name;
    //more attributes
    //获取用户优惠券
    public List<Coupon> findUserCouponList(String id) {
    //implements detail
    }
}

从逻辑上来说，并没有错误，但是如果优惠券有变动的时候，比如更改优惠券类名，更改获取优惠券方式等等，那么User类也要随着更改，这就违反了单一职责原则。用户类应该只包含用户属性，优惠券功能应该由专门的类处理。

所以应该这样更改

用户类

public class User {
    private String id;
    private String name;
    //more attributes
    
}

 优惠券服务类

public class CouponServiceImplement {
    //获取用户优惠券
    public List<Coupon> findUserCouponList(String id) {
    //implements detail
    }
}