【问题标题】:Python OOP Design Pattern for Calculation Flows计算流程的 Python OOP 设计模式
【发布时间】:2021-02-20 02:07:25
【问题描述】:

我对 oop 比较陌生,并且有一个关于编写某种类型计算的最佳方法的快速问题。我很好奇是否存在解决此类问题的既定设计模式。

考虑一个化学工艺流程,您将具有温度、压力、流速等属性的材料 (a,b) 转化为最终产品 c。为了到达那里,我需要单元操作 D、E、F...,每个操作都有自己的一组属性(成本、大小等)。我只需要一个方向的信息流,因为闭环可能会增加复杂性(如果不是,我非常感谢了解闭环的工作原理)。

a,b --> D --> E --> F --> c

最终我希望能够做一个系统成本分析,我会总结 D、E、F 的成本属性。

我目前的处理方法是定义一个“材料”对象,然后让 D 继承材料,E 继承 D... c 继承 F,最后一个“系统”对象继承 c 来分析系统变量。由于我希望能够将 D、E、F 换成 G、H、I,因此还需要用于条件继承的代码,其中 D 必须能够接受输入 a、b(基于定义的属性)和出于同样的原因,E 能够继承 D。我不确定的一件事是对象 c 将如何理解如何总结所有继承对象的属性(可能基于对象/属性的一些一致命名约定?)。

抱歉这个有点冗长的问题 - 如果您知道 AspenPlus,我希望在 Python 中复制一个较小规模的版本(即没有求解器)。感谢您阅读本文!

【问题讨论】:

    标签: python oop design-patterns


    【解决方案1】:

    我认为,在您的情况下,函数式编程实际上比 OOP 更适合,因为它归结为一组对“空白”材料的操作过程,这会产生一种新材料,实际上具有不同的属性。

    如果我受限于 OOP,我会创建不同的类:

    • MaterialType 基本上是字符串或枚举(a、b 和 c)
    • 温度/压力等的外部属性
    • 包含 Material_Type 和旨在转换材料类型的各种属性/函数的材料,例如,它可以包含具有无限外部属性列表的转换函数
    • 进行所有操作的实验室

    这里的对象 c 将是 Material 可以在不继承其他所有内容的情况下计算的 MaterialType。 由于您的示例非常抽象,因此很难提出准确的具体化,但我认为继承带来的问题多于解决方案。

    【讨论】:

      猜你喜欢
      • 2012-05-25
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2021-01-14
      • 1970-01-01
      相关资源
      最近更新 更多