我正在创建某种过滤系统,它基于不同元素接受/产生相同类型的“上下文”。
例如,可以对过程进行建模:
{generate_numbers(1..100)} --> {is_prime} --> {输出}
上下文可以是一个简单的“HashMap”。generate_numbers
创建将“x”设置为某个数字的is_prime
上下文,使用此上下文,查找“x”并相应地放置“prime”=true/false。
优点:
- 灵活性(易于扩展(HashMap))
缺点:
- 无类型值被强制转换
将所有内容声明为“上下文”中的字段也是一种可行的方法,但是这样会牺牲易于扩展性(我可以忍受)
但是......情况有点复杂,因为这些转换器元素分散在应用程序的包中:
{generate_numbers(1..100)} --> {is_prime} --> {calc(f_1)} --> {输出}
{--------------- pkg_A ------} | {--------- pkg_B --------}
所以有些部分 pkg_A 做了一些工作,然后有些部分 pkg_B 部分处理上下文 --> 这就是为什么我想混合这两种方法
我提出了以下想法:
选项1
- 假设我已将包含上下文 E 的基本 HashMap 命名为
- 创建 E 的子类,其中一些条目出现在 getter/setter 可用的字段中
- 在每个处理函数中将传入的参数转换为所需的类类型
亲:
- 相对容易实现
缺点:
- 应该与字段同步 HashMap 内容
- 访问值的方法不止一种可能会导致混淆
选项 2
- 创建一些进行铸造的“工具”类
亲:
- 每个函数都没有子类的运行时强制转换
缺点:
- 访问总是转换为 HashMap 访问
- 每次读取一个字段时都会进行一次强制转换
选项 3
我完全错了,我应该以不同的方式解决问题
更新:
与“如何促进上下文类?” 我的意思是我怎样才能创建一个相对方便的上下文来承载应用程序正在处理的所有杂乱的东西,因为在当前的工作流程中,这些信息被控制逻辑模糊了