标签：单一职责原则   设计模式   职责   类   

      定义

      就一个类而言，应该仅有一个引起它变化的原因。通俗的说，一个类只负责一项职责。

      问题的由来

      手机的功能多，但是每一项的功能都不强：

      拍摄功能——>专业的摄像机和照相机

      手机游戏——>PSP

      网络摄像头——>专业摄像头

      GPS功能——>专业GPS导航系统

      每一个职责都是一个变化的轴线，当需求变化时会反映为类的职责的变化，如果一个类的承担的职责多于一个，那么引起她变化的原因就有多个，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，从而导致脆弱的设计。 

      解决方案

      遵循单一职责原则。分别建立两个类T1、T2，使T1完成职责P1功能，T2完成职责P2功能。这样，当修改类T1时，不会使职责P2发生故障风险；同理，当修改T2时，也不会使职责P1发生故障风险。

    示例

 public interface Program
    {
        void draw();     //绘制图形
        void area();     //计算面积
    }

    public class DrawGraph implements Program
    {
        public void draw()
        {
            System .Out.PrintIn("绘制图形");
        }
        public void area(){}
    }
    public class AreaCount implements Program
    {
        public void draw(){}
        public void area()
        {
            System .out.printIn("计算面积")；
        }
    }

}

以上 图形计算程序只使用了正方形的Area()方法，永远不会使用Draw()方法，而它却跟Draw方法关联了起来。这违反了单一原则，如果未来因为图形绘制程序导致Draw()方法产生了变化，那么就会影响到本来毫不关系的图形计算程序。

应该把接口改成2个，将不同的职责分配给不同的类，使单个类的职责尽量单一，就隔离了变化，这样他们也不会互相影响了。

public interface Draw
    {
        void draw();     //绘制图形
    }

    public interface Area
    {
        void area();    //计算面积
    }

设计模式六大原则——单一职责原则（SRP）

标签：单一职责原则   设计模式   职责   类   

原文地址：http://blog.csdn.net/zlts000/article/details/24798049