0. 老实交代，最近对于python，非常之感冒
热天气常驻之后，各种毛病就来了：蚊子很彪悍，牙齿不舒服，肠胃那更是一坨 …
虽然不久前，荷包大残，但是关注到 mac mini 之后，就想拿下一个 丐中丐，其实也没啥大不了的，就是摸一摸 mac os
最近发现 microhard 的 翻译，搜索 居然可圈可点，那么 … 反观 … 。有趣的时候，某言回答一些编程问题的时候，经常是多问一句，马上承认错误 … 我真的是 ******
b 话少叙，时间不早了，希望后面的开发，可以削微顺遂一些 …
其实之前就一直想设计 一种可以在 运行时解释 的序列，一直拖到最近，并且这俩周，一边开发，一边还在不断重构这个设计
那么好 … 这次在集成 分布式缓存 的时候，也顺便的基于 这个序列，构建了一些字符串
Pajamas
1. 这个点，原谅我没有时间手绘美图
一开始，为了严格支持 规则配置，继承。本来想让 让规则信息 mutable 的，后面发现，这么做的话，集成到项目 以及 在后面使用的过程中，发现这么搞 除了 拖沓，就是冗余。最**关键，代码语义性不好，这是绝不能接受的。
本着最好是，尽量少的注释，尽量少的文档 的前提，那么，就应该从编程的角度去思考，不是从逻辑的角度出发。主要是 java 发展到现在，作为一门应用语言，关键就是一个维护…
1.1 简单过一下
这仨基本上，是各种使用方式中， 最少会直接接触到的类(结构)
下面这个长句 也是我 在重构的时候 的思路
我们早在项目初始化时，就可以配置模板(template)了；在需要序列(sequence)的地方，使用这个 模板(template) 创建(create)出 合乎我们格式的 序列(sequence)；这一个序列(sequence)等到 运行过程中，我们可以有 不同的使用方式(code/aspect) ，在不同的上下文中(context)， 根据动态的入参去 解释(interpret) 出不同的语义
1.2 设计完之后，反过来看这里面的逻辑
挖个坑先：用 Astah 画一下 构建，传递 过程
