OO system是Mathematica中OOP的免费开源软件包。通过使用面向对象系统，我希望受益于两全其美（OOP / Functional）。
答案 0 :(得分：5)
免责声明：我没有使用任何现有的OO mma扩展（特别是OO系统），因此这篇文章基于一般参数（但我在Java中工作时使用了大量OO，并使用了一些OO元素妈妈，我自己实施的）。我同意opinion OO是一个移动目标，所以你必须在你想要的功能方面更加具体，以获得更有用的答案。它还在很大程度上取决于您的目标 - 您希望简化自己的生活并制定自己的项目规模，还是希望简化将由多个（许多）开发人员开发的项目的通信，以及强制执行某些规则和协议（编码标准，最佳实践，设计模式，等等），或者您是否希望OO重用现有库。
我认为行业中大多数OOP的使用属于第二和第三类。如果这也是你的情况（我怀疑它不是这样），那么在Mathematica中使用OOP可能是有意义的，尽管这还不清楚。例如，WolframAlpha在其代码库中拥有数千万行代码，并且在那里使用了AFAIK no OO系统。如果你想为独奏开发者带来好处，那么我会选择我喜欢的OO功能并自己实现它们 - 即创建自己的对象模型。这在Mathematica中并不太难。
如果使用此扩展构建大量经过充分测试的开源库，并使用简单的部署机制，那么使用Mathematica的某些特定OO扩展会更有意义。我不知道任何使用任何现有OO mma扩展构建的重要mma代码库（库）（这也可能是由于我的无知）。因此，如果您需要OO来重用现有的库，那么诸如J / Link或.Net / Link之类的东西可能会为您提供更好的服务，因为您可以访问所有Java或.Net。
如果您想要扩展项目的技术，那么OO不是您唯一的朋友。虽然这对于mma来说可能不是一个非常好的探索领域（除了可能由WRI），但是其他函数语言的一些技术，例如闭包，LISP宏，运行时代码生成等，可能适用于mma。例如，我正在处理的一个mma项目有40多个软件包和超过1万行mma代码，并且它具有很强的可管理性（使用WorkBench）。我正在使用闭包和宏，还有一些OO功能，但不是任何通用的OO扩展。重要的是信息隐藏，失去耦合，可组合性和可测试性，同样，OO不是唯一的方法。
IMO，一个非常好的事情可以通过mma中支持OO的语言层（也许是类似Python）来实现，可以隐藏评估器和模式匹配器的复杂性，因为在很多情况下这些都不是需要并且可能会让经验不足的用户感到困惑。我曾经（现在仍然）错过了很多这样的语言层。这一层的设计者将面临一项艰巨的任务，即使其与mma的其余部分完全融合。除此之外，我看到了在顶级mma中构建的通用OO系统的两个主要障碍：性能低下并且没有自动垃圾收集。我认为，在这些问题得到解决之前，它们排除了在较低级别（创建数百万个对象等）的OOP的大量生产使用。 OOP的某些功能对于高级项目架构仍然非常有用，但正如我所说，它们很容易实现。这并不是说您不应该尝试现有的OO扩展，我只是专门针对mma加权，以防止它们对您的代码施加的必要限制。答案 1 :(得分：1)
您可能还会发现MathOO很有趣（请注意，我从未使用过它）。