设计模式之单一职责原则

2017-01-20

单一职责原则

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

分析

电话通话的时候有四个过程发生：拨号、通话、回应、挂机，如下所示:

下面是具体代码实现：

/**
 * 类描述:
 *
 * 
 * @date:2016/12/5
 * @修改描述：
 * @modifier ${tags}
 */
public interface IPhone {

    void dial(String phoneNum);

    void chat(Object o);

    void hangup();
}

上面的代码看起来没有问题，但是单一职责原则要求一个接口或者类只有一个原因引起变化，也就是说一个接口或者类只有一个职责，它就负责一件事，上面的接口显然并不是只负责一件事情。
IPone这个接口可不只是有一个职责，它包含了两个职责：一个是协议管理，一个是数据送达。dial()和hangup()两个方法实现的是协议管理，分别负责拨号和挂机；chat()是实现数据送达。
下面分析上面存在的问题。第一，协议变化显然会造成接口或者类引起变化；第二，数据传送也会造成接口或者类引起变化。
分析发现，上面的接口包含了两个职责，而且两个职责互不影响，所以考虑拆分为两个接口。如下图所示:

// 代码描述

public interface IDataTransfer {

    void chat(IConnectionManager iConnectionManager);
}

public interface IConnectionManager {

    void dial(String phoneNum);

    void hangup();
}

/**
 * 类描述:电话具有拨打电话、挂断电话、通话的功能
 *
 * 
 * @date:2016/12/5
 * @修改描述：
 * @modifier ${tags}
 */
public class Phone implements IConnectionManager, IDataTransfer{


    public void dial(String phoneNum) {

    }

    public void hangup() {

    }

    public void chat(IConnectionManager iConnectionManager) {
        
    }

}

总结 单一职责原则优点

• 类的复杂性降低，实现什么职责都有清晰明确的定义；
• 可读性提高，复杂性降低，那当然可读性提高了；
• 可维护性提高，可读性提高，那当然更容易维护了；

• 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。

  分析

  对于接口，我们在设计的时候一定要做到单一，但是对于实现类就需要多方面考虑了。生搬硬套单一职责原则会引起类的剧增，给维护带来非常多的麻烦，而且过分细分类的职责也会人为地增加系统的复杂性。本来一个类可以实现的行为硬要拆成两个类，然后再使用聚合或组合的方式耦合在一起，人为制造了系统的复杂性。

转载于:https://www.cnblogs.com/d9527/p/6322706.html