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