Wolfram mathematica 面向对象的mathematica编程

我想知道一般如何做，最好的策略是什么，等等。我看到了一些解决方案，其中一些看起来很难使用。我研究的那个使用纯函数来实现对象函数和像object[]这样的头部。在类编码方面很难使用它。我在定义函数和构造函数时感到头晕目眩（尤其是继承部分很难）

所以我的问题是关于类的编码部分的元素。理想情况下，我正在寻找的东西，将工作如下。首先，我们定义了一个类，例如car，如下所示：

beginClass["vehicle"];
   public startTheEngine;
   private fuel;
   vehicle[args_]:=Block[{},...];
   startTheEngine[thrust_]:=Block[{}...];
endClass

beginClass["car", "vehicle"];
public TurnTheRadioOn;
private frequency;
car[args_] := Block[{...},];
TurnTheRadioOn[]:=
   Block[{},
      use private variable frequency
   ]
endClass;

请注意，私有/公共函数的定义几乎与“普通”mathematica代码中的定义相同，这一点非常重要。可以说，这是主要的要求

该类将用作

car1 = newObject["car", args];
car1.StartTheEngine[];
car1.TurnOnTheRadio[];

我很好奇这个人要想什么？构建上述内容可能涉及Mathematica的许多方面，例如，如何修复“.”语法等。如果您建议使用现有软件包，如果您能就其工作原理发表意见，我将不胜感激

我天真的期望是封装部分可以通过BeginPackage构造来修复。所有对象都可以存储在专门为每个类设计的名称空间中。我猜物体看起来像

car1 = OBJECT["car"][fuel$1,frequency$1,....];
car2 = OBJECT["car"][fuel$2,frequency$2,....];

我假设必须构造类似编译器的东西，将上面的类定义代码转换为class.m文件。另外，在某种程度上，第二个主要问题是如何构造这样的编译器

问候 佐兰

p、 我之所以问这个问题，是因为我确实需要很多次这样的东西

请参阅我的帖子，其中我讨论了一种实现类似于您要求的东西的方法。这不会为您提供对象系统、继承或OO的多态性特征，但从您的表述来看，您似乎在寻找构造ADT（抽象数据类型）的方法，而不是成熟的OO扩展。对于使用以这种方式构造的可变数据结构的一个非平凡示例，您可以查看

---

至于Mathematica中的OO，您还可以查看一些相关的过去讨论，包括SO和MathGroup。我知道有一次，我在那里作了答复，并表达了我对此事的一些想法。您还可能会发现，这是最近的一篇文章，它提供了与Mathematica中过去关于结构的讨论的链接，这很有趣。

Mathematica语言是针对结构进行优化的，当您停留在该范例中时，它提供了最大的杠杆作用和便利。面向对象编程是对符号范式的重大背离，最终不得不从头开始编写大部分支持基础设施。当然，这本身并没有什么问题，但利用该功能并用Java编写OOP代码的工作量要小得多。这使得Mathematica和Java代码很容易混合

思考是什么需求推动人们朝着面向对象的解决方案发展，这将是富有成效的。这个问题表明，人们的兴趣在于如何实现，但可能还有其他问题，如封装和多态性。似乎还有一些更具体的后续问题，比如“Mathematica与面向对象的习惯用法X的等价物是什么？”

OOP被认为是有害的？

在Mathematica的上下文中，面向对象编程甚至可能被认为是有害的。OO强调创建“黑盒”对象，外部调用方无法访问其内部。虽然这对通过信息隐藏控制复杂性有明显的好处，但它确实直接与符号编程的威力背道而驰。Mathematica强调看似不相关的组件之间的协同作用，允许将一个组件的符号表示转换为另一个组件的符号表示。“黑匣子”在这个生态系统中不起作用。作为一个具体的例子，对比一下

图形

“对象”和新的V8

图形

对象之间的差异。后者采用某种OO方法——在社区中生成一些

---

这并不是说OO本质上是有害的。本次讨论的重点是，面向对象对Mathematica生态系统来说是陌生的，通过选择这种设计，人们可能会排除未来某些理想的协同效应。有意识地做出决定。

谢谢。我会检查的。请查看编辑/更改。如果可能的话，最好有完整的OO。只是为了讨论。“如果以这种形式证明任务是不可能的，那么我们可以试着简化。”我明白了。但是添加真正的继承/多态性/子类化/子类型化真的是一堆麻烦。做这件事的方法有很多，只有少数几种方法是正确的/好的。您必须考虑覆盖方法和字段和/或访问父级方法和字段的规则、构造函数调用的顺序、编写动态函数调度代码以及其他许多内容。你确定你会那么需要OO类型的继承/多态性吗？Mathematica提供了其他方法来实现相同的最终结果，例如模式和基于模式的函数分派。如果你只有一把锤子，你会看到到处都是钉子。但这远比试图教一个螺丝钉遵守这一点要好得多。拧紧（拧紧）@belisarius同意：）但是OTOH，我确实从过去的OO经验中受益匪浅，即使我现在不写OO代码。我认为它强调了在编码、信息隐藏和关注点分离之前思考/设计的一些良好实践。在FP中，总是遵循自下而上设计的诱惑太容易了，这在IMO中并不总是一个好主意。@Leonid当然我可以看到自上而下设计（和思考）的优势，但OO并不是结构化设计的唯一铺平道路