七大设计原则|单一职责原则的实践

我们并非一定要完全遵循设计原则，但是有时候运用设计原则，能使我们的代码更加规范，易于维护。

在2017年时封装过hessian的一个业务类，但是在使用的时候，由于方法名类似，参数不同，很容易出错。

刚好学习 单一职责原则，就想实践体验下，设计原则的好处。

---

单一职责（Simple Responsibility Pinciple，SRP）是指不要存在多于一个导致类变更的原因。假

设我们有一个Class 负责两个职责，一旦发生需求变更，修改其中一个职责的逻辑代码，有可能会导致

另一个职责的功能发生故障。这样一来，这个Class 存在两个导致类变更的原因。如何解决这个问题呢？

我们就要给两个职责分别用两个Class 来实现，进行解耦。后期需求变更维护互不影响。这样的设计，

可以降低类的复杂度，提高类的可读性，提高系统的可维护性，降低变更引起的风险。总体来说就是一

个Class/Interface/Method 只负责一项职责。

---

下面先上原来的业务代码

呵呵，不忍直视。这是我写的。

分析下这些方法，前面三个create是主业务方法，应当是运用在不同的业务层场景的。但是，这样非常的混乱。

下方的三个方法从命名其实也是不怎么正确的，看了下代码，其实是判断url是否合法的校验。

想必调用这些方法的同事们，心里在默默骂着呢。

运用单一职责原则，这三个方法应当抽出来写成3个类，下方3个方法可以抽出来写成一个类，且类的命名必须能够正确且清晰的说明功能。

绿色为新类

HessianProxyFactory对应方法

public static Object create(Unit unit, String apiName , Class interfaceClass , String account)throws Exception

apiName 可以根据interfaceClass 获得，因此可以删除这个参数。

基本类

下面两个是根据不同的客户端角色创建两个类

平台调用

微信公众号用户调用

这样的话，实现了每个类拥有明确的单一职责，调用也是比较方便。