模板与实例在系统中的应用
模板与实例在系统中的应用
模板是什么
模板定义了通用的结构和行为，包含了一系列方法和属性，这些方法和属性为系统提供了参考。
实例是什么
实例是模板的具体实现，继承了模板的结构和行为，并为模板中的抽象和属性提供了实现。
模板是定义系统有什么功能，实例就是这些功能的具体实现。在系统设计上，如何识别出产品描述的需要什么功能和如何实现功能这点上，如果有理论支撑，将规避不少系统设计的坑。
例如
产品需要设计一个会员系统，用户在系统下单购买了年卡商品就会开通会员。
需求如何转化成系统设计
我们需要设计一个后端操作界面，让运营能够配置对应的年卡商品。
用户在下单时，订单里有年卡商品，就要给用户生成一个会员。
在这个描述中，运营创建的每一条记录为模板，用户按模板生成的每一条记录为实例。
那么开通会员是我们的实例，而创建实例需要用户下单购买了年卡商品，那么购买动作是发起创建实例的开始，购买年卡商品是创建实例的条件
后续，如果会员系统要指定用户购买指定商品就开通会员。
那么模板上就是指定用户和指定商品。
实例化会员的时候，判断条件就多了指定用户和指定商品的判断。
总结出3个要素
- 模板
- 实例
- 动作
线下门店做会员日活动，要求每个门店能够自主决定做会员日的日期和选择什么样的礼品，系统怎么设计？
实例：会员日活动
动作：门店能创建活动实例
模板：一个会员日活动所需要具备的信息列表
这种方式与类结构异曲同工
类中的属性就是模板字段
类中的实例就是这个模板字段的实例化对象
类中的方法就是动作
所以，有些规律只要想明白了，总能找到与之相通的实现。
模板实例-工厂模式
这几个要素就能设计出一个系统雏形，现实场景中，功能特别多，当功能多了以后，就会有各种分类、组合等组成一个庞大且复杂的系统。
对于这种功能越来越多，组合方式也越来越多的情况，类似于设计模式中的factory，创建复杂实例不是简单的new出来，而是需要各种数据协调，有些实例创建只需要简单几个参数，有得需要借助其他平台的数据才能完成。对于使用者来说，不需关心系统是如何创建的，只需要关心自己关心的业务即可。
当业务再复杂点，还是每个门店能自主创建会员日活动，但每个会员日活动又不一样。比如有些需要送礼品，有些不需要送礼品，这时候的解法如下。
实例：会员日活动
动作：门店创建
模板：日期选择区间，活动A可选礼品，活动B不可选礼品
来到这一步，就发现，业务变化的条件不是创建实例上，而是创建实例的源头，模板的变化导致实例化也要跟着变，那么我们的解决办法是什么了
模板实例-抽象工厂模式
首先，工厂模式是模板+数据生成实例，那么抽象工厂模式就是不同条件的模板 + 数据生成不同类型实例。关键点是要生成功能相似对象，只是抽象工厂多了变量，创建者本身是不同类型的，在创建工厂时，需要将变量作为条件。
模板与实例是一种创建型设计，是设计模式中的工厂模式，业务的变化无限，但设计有限。将业务语言翻译成系统语言，一套成熟的方法论能保证系统非常强大且容易维护。
这套理论，延展到领域模型、数据表设计、代码实现也同样适用。
模板实例在领域模型中的应用
在领域建模型的时候，都是建的模板，系统中真实生成的每一条数据是一个一个的实例。比如建立一个会员活动
定义活动需要名称、时间、区域等，这是活动模板
录入信息生成一个活动，这是一个活动实例
定义活动需要录入会员商品，这是会员模板
录入一个商品，这是会员活动实例
用户参与活动购买会员商品，生成一个会员记录，这是会员实例
会员实例是通过参考会员活动实例生成的，所以，会员活动实例在会员实例角度来看，这是它的模板！
这点很重要，这是我们设计系统最理不清楚概念的地方。
模板实例在数据表中的应用
我们建的任何一张表都可以理解为模板，每插入的一条数据都可以认为是实例，这是最简单最容易理解的方式。
随着时间和业务的加入，一个表最开始是无限加入字段，来满足业务需求，那样就无法表达不同属性的一对一，一对多关系，进而引入了类似json字符串的形式来表达1对多。
而实际运用中，这种方式收益是可观的，如果某块业务不发展了或发展缓慢，我们的表并没有因为业务原因而建了冗余的表。
但如果业务发展迅速，设计表时，单1字段用来表示1对多关系已经不合适了，这时候，我们只需要再建一张表，这张表持有原表的id就能表达清楚了。而新表就是模板的扩展，新表数据也是实例扩展。
结束语
模板实例是设计系统时一个起步的概念，属于创建型理论。在设计创建型系统时，拿这个理论作指导思想，将有效避免一些无设计的坑。模板实例概念很多思考都是参考自24种设计模式中的创建型模式。
