1.定义
一个类只做一件事，只有一个原因引起变化
2.作用
- 降低类的复杂度
- 降低变更带来的风险
- 提高系统维护性
3.应用
下面是一个画图接口
public interface Drawing {
//画正方形
public void DrawSquare();
//画三角形
public void DrawTriangle();
//画一条线
public void DrawLine();
//画一个曲线
public void DrawCurve();
}
这个接口的设计有问题吗？我说是没有问题的。单一职责原则要求一个接口或类只有一个原因引起变化，一个接口或类只有一个职责，只负责一件事情。画图接口也确实是按照单一职责去设计只负责画，里面的方法也都是draw的相关方法，如果在需求不会变化或者变化的可能性比较小，那么这种设计就是合理的。但实际情况我们知道，随着业务的不断增加，产品的脑洞越来越大下次需要增加，圆形，椭圆形，二阶三阶贝塞尔曲线等等，这个时候我们就需要改，有时候可能还会牵扯到连带关系也要发现改动。所以更好的方式是按照draw的类型进行拆分。拆分成DrawFigure专门用来处理画图形，DrawPoints专门用来处理画线条
public interface DrawFigure {
//画正方形
public void DrawSquare();
//画三角形
public void DrawTriangle();
}
public interface DrawPoints {
//画一条线
public void DrawLine();
//画一个曲线
public void DrawCurve();
}
这样做更符合了单一职责原则，假如下次增加了其他图形的功能，经过我们的拆分接口之后我们只需要在处理图像接口中新增加就行，比起最开始来说降低了变更的风险和复杂度，不用去修改所有实现了了画图接口Drawing的实例
4.总结
不管是接口或者是类还是方法都建议遵循单一职责原则，但是具体要细化到哪一步，还是要取决于需求和业务的复杂度。
