项目背景
现在有一个类似于注册用户的模块功能。不同乙方有不同的入参需求和逻辑处理，但是其中有可以提取的公共组件部分和逻辑组件部分。
老代码使用基础的if或者是一个实例对象作为一个判断基础。导致代码混杂冗余，逻辑不清，维护和拓展都比较困难。现在希望从设计模式的角度出发。重构这个模块的代码。使其逻辑清晰易懂，以维护易拓展。
需要解决的问题
- 如何提高代码的复用性
- 如何提高代码的可维护性
- 如何保证代码的拓展性
- 如何实现最后只有一个出口
思路
首先，复用性和拓展性的问题可以一起考虑。从es6正式引入class之后，类的特性正是解决该类问题的好方法。
类之所以能够解决这两个难点，重点在于继承和多态的使用。从而使得业务代码高度解耦，也同时解决了维护性的问题——因为只要维护某一个子类的就可以了。
在如何保证最后只有一个出口这个问题上，我们可以采用策略模式的思想。用某种规则去决定所需要继承的类。我们只要传入参数，策略将为我们自动选择所继承的类，最后输出一个页面真正需要的特化类。
名词讲解
模板模式
模板方法模式是一种只需使用继承就可以实现的非常简单的模式。模板方法模式由两部分结构组成，第一部分是抽象父类，第二部分是具体的实现子类。通常在抽象父类中封装了子类的算法框架，包括实现一些公共方法以及封装子类中所有方法的执行顺序。子类通过继承这个抽象类，也继承了整个算法结构，并且可以选择重写父类的方法
假如有一些平行的子类，各个子类之间有一些相同的行为，也有一些不同的行为。如果相同和不同的行为都混合在各个子类的实现中，说明这些相同的行为会在各个子类中重复出现。但实际上，相同的行为可以被搬移到另外一个单一的地方，模板方法模式就是为解决这个问题而生的。在模板方法模式中，子类实现中的相同部分被上移到父类中，而将不同的部分留待子类来实现。这也很好地体现了泛化的思想。
重点： 公共部分抽离 在子类中重写方法
策略模式
在程序设计中，常常遇到类似的情况，要实现某一个功能有多种方案可以选择。比如一个压缩文件的程序，既可以选择zip算法，也可以选择gzip算法。这些算法灵活多样，而且可以随意互相替换。这种解决方案就是本文将要介绍的策略模式。策略模式是指定义一系列的算法，把它们一个个封装起来，并且使它们可以相互替换
重点： 策略模式应该是平行的，是可以互相替换的，替换后会产生不同/相同的效果。
具体设计
技术栈为React，这里选择将渲染部分和和逻辑处理部分分开
component红框部分即为渲染类部分，由一个基本类和多个特化类构成
model红框部分为逻辑类部分，由一个基本类和多个特化类构成
component 继承 model ，model继承 React.component
实现
设计具体涉及业务代码。。这里就不放了。以后有时间写个demo补上
