我们并非一定要完全遵循设计原则，但是有时候运用设计原则，能使我们的代码更加规范，易于维护。
在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 获得，因此可以删除这个参数。
下面两个是根据不同的客户端角色创建两个类
这样的话，实现了每个类拥有明确的单一职责，调用也是比较方便。
