模板与实例在系统中的应用

模板与实例在系统中的应用

模板是什么

模板定义了通用的结构和行为，包含了一系列方法和属性，这些方法和属性为系统提供了参考。

实例是什么

实例是模板的具体实现，继承了模板的结构和行为，并为模板中的抽象和属性提供了实现。

模板是定义系统有什么功能，实例就是这些功能的具体实现。在系统设计上，如何识别出产品描述的需要什么功能和如何实现功能这点上，如果有理论支撑，将规避不少系统设计的坑。

例如

产品需要设计一个会员系统，用户在系统下单购买了年卡商品就会开通会员。
需求如何转化成系统设计
我们需要设计一个后端操作界面，让运营能够配置对应的年卡商品。

用户在下单时，订单里有年卡商品，就要给用户生成一个会员。

在这个描述中，运营创建的每一条记录为模板，用户按模板生成的每一条记录为实例。

那么开通会员是我们的实例，而创建实例需要用户下单购买了年卡商品，那么购买动作是发起创建实例的开始，购买年卡商品是创建实例的条件

后续，如果会员系统要指定用户购买指定商品就开通会员。
那么模板上就是指定用户和指定商品。
实例化会员的时候，判断条件就多了指定用户和指定商品的判断。

总结出4个要素

1. 模板

2. 实例

3. 动作

4. 条件

线下门店做会员日活动，要求每个门店能够自主决定做会员日的日期和选择什么样的礼品，系统怎么设计？

实例：会员日活动
条件：选择日期、选择礼品
动作：门店创建
模板：日期选择区间，可供选择的礼品列表

这几个条件就能设计出一个系统雏形，现实场景中，功能特别多，当功能多了以后，就会有各种分类、组合等组成一个庞大且复杂的系统。
对于这种功能越来越多，组合方式也越来越多的情况，类似于设计模式中的factory，创建复杂实例不是简单的new出来，而是需要各种数据协调，有些实例创建只需要简单几个参数，有得需要借助其他平台的数据才能完成。对于使用者来说，不需关心系统是如何创建的，只需要关心自己关心的业务即可。

当业务再复杂点，还是每个门店能自主创建会员日活动，但每个会员日活动又不一样。比如有些需要送礼品，有些不需要送礼品，这时候的解法如下。

实例：会员日活动
条件：选择日期、选择礼品
动作：门店创建
模板：日期选择区间，活动A可选礼品，活动B不可选礼品

来到这一步，就发现，业务变化的条件不是创建实例上，而是创建实例的源头，模板的变化导致实例化也要跟着变，那么我们的解决办法是什么了，参考抽象工厂模式。

首先，工厂模式是模板+数据生成实例，那么抽象工厂模式就是不同条件的模板 + 数据生成不同类型实例。关键点是要生成功能相似对象，只是抽象工厂多了变量，创建者本身是不同类型的，在创建工厂时，需要将变量作为条件。

模板与实例是一种创建型设计，是设计模式中的工厂模式，业务的变化无限，但设计有限。将业务语言翻译成系统语言，一套成熟的方法论能保证系统非常强大且容易维护。

这套理论，延展到领域模型、数据表设计、代码实现也同样适用。