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

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 分钟卖出
最新回复 (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
返回