需求里充斥着大量条件判断，有什么好的设计模式，便于后期维护的？之前记得重构那本书里面是每个判断写成一个类

yagamil 20天前 8

需求里面这样的，这些变量是由用户填写的，所以也不能根据自己的想法吧冗余的合并了，而且用户自己填错没有执行到判断，这个是用户自身问题，也不做提示。

不同的字母代表不同的值，当然可以设置为一样的
T1 分钟内涨幅≥A1 且 起始涨幅＞ B1 则买入后 S1 分钟卖出，
T2 分钟内涨幅≥A2 且 起始涨幅＜ B2 则买入后 S2 分钟卖出，
T3 分钟内跌幅≥A3 且 起始涨幅＞ B3 则买入后 S3 分钟卖出，
T4 分钟内跌幅≥A4 且 起始涨幅＜ B4 则买入后 S4 分钟卖出，

T5 分钟内 C5≤涨幅＜ A5，且 起始涨幅＜ D5，则买入后 S5 分钟卖出
T6 分钟内 C6≤涨幅＜ A6，且 起始涨幅＞ D6，则买入后 S6 分钟卖出
T7 分钟内 C7≤跌幅＜ A7，且 起始涨幅＞ D7，则买入后 S7 分钟卖出
T8 分钟内 C8≤跌幅＜ A8，且 起始涨幅＜ D8，则买入后 S8 分钟卖出

上一篇：请问不开源的软件又不收费，靠什么盈利？

下一篇：有老哥来聊聊 2021 年有上市前景的公司吗(财富自由)

最新回复 (34)

DTCPSS 15天前

引用 2楼

表驱动？
turan12 15天前

引用 3楼

这是量化交易系统的条件判断？
abersheeran 15天前

引用 4楼

任何形式都不能去除最基本的 if else 判断。你只能隐藏它们。
xx6412223 15天前

引用 5楼

没记错的话，应该是责任链模式，
mmdsun 15天前

引用 6楼

适合用规则引擎做？
skymei 15天前

引用 7楼

责任链模式或者策略模式
楼主 yagamil 15天前

引用 8楼

@turan12 是的，用户就是提出这样的需求。后期也可能回新增条件。
楼主 yagamil 15天前

引用 9楼

@abersheeran 是的，尽量避免嵌套大约 3 层的 if else，加上后期维护。
cmdOptionKana 15天前

引用 10楼

感觉这种没有规律且不受控制的（客户随时提出改动的）条件，用 if else 写死就很好，反正一共也没几行。

当客户提出的情况越来越复杂，多数情况下都可以进行分类处理，但每个类别里面基本上也是写死几种特殊情况。
andj4cn 15天前

引用 11楼

pipeline
billlee 15天前

引用 12楼

如果是需要由运营人员随时改动的，还是适合做成规则引擎配置化

如果钱给得不够做不了规则引擎，那还是 if ... else 吧，更好维护。这种需求搞一堆类才是无法维护的。
akira 15天前

引用 13楼

这其实就只有 2 个规则呀
bugmakerxs 15天前

引用 14楼

责任链
GeruzoniAnsasu 15天前

引用 15楼

啊？规则是使用者定义的，你为什么想要 build in 到系统里？

难到不是应该实现一个 parser 然后就把你展示的这段文本作为配置输入吗
laike9m 15天前

引用 16楼

没懂为什么需要设计模式
turan12 15天前

引用 17楼

@yagamil 以前碰到过一个决策树系统，和这个很类似，在使用过程中这些条件肯定是需要频繁修改的。当时的做法是直接把条件语句写入数据库，并指定执行优先级。需要时直接 order by 以后读取执行即可。
Mithril 15天前

引用 18楼

做成规则引擎，而且你这就是简单的 if else，很好做。弄个 JSON 配置文件直接读进来当表判断就行了。
然后剩下的都是 PM 和策划的活了。反正它们自己写的配置搞成死循环了也不关你的事。
xinhaiw 15天前

引用 19楼

反射
gouflv 15天前

引用 20楼

如果只是这几种情况，做可视化都可以了
JJstyle 15天前

引用 21楼

写成配置，然后反解析
楼主 yagamil 15天前

引用 22楼

@turan12
@akira
@billlee
@cmdOptionKana 谢谢大家。
最后觉得就类的方式，每个决策做成一个类，主要为了后期维护方便

```
class BaseStrategy():
def __init__(self,
strategy_number=None,
monitor_time=None,
monitor_raise_min=None,
monitor_raise_max=None,
start_raise=None,
sell_time=None,
):
self.monitor_time = monitor_time,
self.monitor_raise_min = monitor_raise_min,
self.monitor_raise_max = monitor_raise_max,
self.start_raise = start_raise,
self.sell_time = sell_time,
self.strategy_number = strategy_number

def valid(self):
return True if self.monitor_time else False

def match_time(self, current):
return True if current >= self.monitor_time else False

def get_sell_time(self):
return self.sell_time

def start_raise_condition(self, v_value):
if self.strategy_number % 2 == 0:
return True if self.v_value < self.self.start_raise else False
else:
return True if self.v_value > self.self.start_raise else False

def meet(self, current, interval_raise_val, start_raise_val):
if self.valid() and self.match_time(current) and self.interval_raise(interval_raise_val) and self.start_raise_condition(start_raise_val):
return self.get_sell_time()
else:
return None

class StrategyCondition1(BaseStrategy):

def interval_raise(self, v_value):
return True if self.v_value >= self.self.monitor_raise_max else False

class StrategyCondition2(BaseStrategy):

def interval_raise(self, v_value):
return True if self.monitor_raise_min <= self.v_value < self.self.monitor_raise_max else False
```
shyrock 15天前

引用 23楼

规则引擎就是适配这种需求的。
如果你的规则希望直接由业务人员定义，而且需要灵活变更规则，那么规则引擎比内置的设计模式要合适。
zhuweiyou 15天前

引用 24楼

更倾向于做 parser
guyeu 15天前

引用 25楼

万事不决 DSL
annielong 15天前

引用 26楼

那就是一个设计器，最后根据条件生成判断，
matrix67 15天前

引用 27楼

table driven

有个 asq lib

https://github.com/sixty-north/asq/blob/master/asq/examples/pupils.py
pancl 15天前

引用 28楼

写表
shm7 15天前

引用 29楼

规则本身很规范的话，批量处理规则就成为了肯能
1more 15天前

引用 30楼

规则引擎或者 groovy 脚本引擎，后期维护事实和规则就行
cubecube 15天前

引用 31楼

不要用责任链，除了增加别人的阅读障碍，没有任何明显提升。代码块抽成函数调用，好好取函数名即可。
我就旗帜鲜明的喜欢 if else
no1xsyzy 15天前

引用 32楼

JetBrains MPS ？

我看到了什么？
> return True if self.v_value < self.self.start_raise else False
LeeReamond 15天前

引用 33楼

@matrix67 他是 python，所以实际不是表驱动，更像是 mapdriven，哪个快不好说，大概率更慢
matrix67 15天前

引用 34楼

@LeeReamond #32 这种逻辑一般不会是瓶颈吧。。。
LeeReamond 15天前

引用 35楼

@matrix67 因为 python 本身慢，再加上没有 switchcase，这种逻辑比原生可能慢个几百倍。有重复运算的部分很容易瓶颈，确实需要找优化方案
游客

36楼