Mathematica OO系统(或替代品)? [英] Mathematica OO System ( or alternatives )?

问题描述

OO系统 是一个免费的开源软件包在Mathematica中用于OOP.我希望通过使用OO-System可以从两全其美(OOP/功能性)中受益.

OO system is a free, open source package for OOP in Mathematica. By using OO-System I hope to benefit from the best of both worlds (OOP/Functional).

• OO的作用和不该做什么 Mathematica系统?
• 您是否知道(更好)开放 来源替代品?
• 您愿意展示您的一些作品吗? OO系统类?
• 关于OOP的任何评论都与 Mathematica吗?

• What are the do's and don'ts of OO System for Mathematica?
• Are you aware of (better) open source alternatives?
• Are you willing to show some of your OO-system classes?
• Any remarks about OOP in general with Mathematica ?

推荐答案

免责声明:我没有使用过任何现有的OO mma扩展(特别是OO System)，所以本文基于一般性论点(但我在Java中工作时大量使用OO，并在mma中使用了一些OO元素，这是我自己实现的).我同意意见 OO是一个不断发展的目标，因此您必须在术语上更具体所需的功能，以获得更有用的答案.它还很大程度上取决于您的目标-您是要简化自己的生活并建立自己的项目规模，还是要简化将由多个(许多)开发人员开发的项目的沟通，以及强制执行某些规则和协议(编码标准，最佳实践，设计模式等)，或者您希望OO重用现有的库.

A disclaimer: I have not used any of the existing OO mma extensions (and OO System in particular), so this post is based on general arguments (but I used OO heavily when worked in Java, and used some OO elements in mma, which I implemented myself). I agree with the opinion that OO is a moving target, so you have to be more specific in terms of features you want, to get a more useful answer. It also greatly depends on what are your goals - do you want to simplify your own life and make your own project scale, or do you want to simplify the communication for the project which is going to be developed by several (many) developers, and enforce certain rules and protocols (coding standards, best practices, design patterns, whatever), or do you want OO to reuse existing libraries.

我认为，该行业中大多数OOP的使用都属于第二和第三类.如果这也是您的情况(我怀疑不是)，那么即使在不清楚的情况下，在Mathematica中使用OOP还是有意义的.例如，WolframAlpha在其代码库中有数千万行代码，并且那里没有使用AFAIK没有OO系统.如果您想为单独的开发人员带来好处，那么我将选择我喜欢的OO功能并自己实现这些功能-即，创建您自己的对象模型.在Mathematica中，这不太困难.

I'd argue that most of OOP use in the industry fall into the second and third categories. If this is also your case (which I suspect it is not), then it may make sense to use OOP in Mathematica, although even this is not clear. WolframAlpha, for example, has tens of millions of lines of code in its codebase, and AFAIK no OO system was used there. If you want the benefits for the solo developer, then I'd choose those features of OO that I like and implement them myself - i.e., create your own object model. This is not too difficult in Mathematica.

如果将使用Mathematica的某些OO扩展进行扩展，并且使用易于部署的机制构建大量经过良好测试的开放源代码库，那将更有意义.我不知道使用任何现有的OO mma扩展构建的任何重要的mma代码库(库)(这也可能是由于我的无知).因此，如果您需要OO重用现有的库，那么J/Link或.Net/Link之类的东西可能会为您提供更好的服务，因为您将可以访问所有Java或.Net.

It would make much more sense to use some specific OO extension of Mathematica if there would be a large number of well-tested open-source libraries built using this extension, with an easy deployment mechanism. I am not aware of any significant mma code base (libraries) built with any of existing OO mma extensions (which could as well be due to my ignorance). So if you need OO to reuse existing libraries, then things like J/Link or .Net/Link may serve you better, since you will have access to all of Java or .Net.

如果您希望这些技术可以扩展您的项目，那么OO不是您的唯一朋友.尽管对于mma来说，这可能不是一个很好的研究领域(WRI可能除外)，但是其他功能语言中的某些技术(例如闭包，LISP宏，运行时代码生成等)也很可能适用于mma.例如，我正在从事的mma项目之一有40多个软件包和1万行以上的mma代码，而且它非常易于管理(使用WorkBench).我经常使用闭包和宏，还有一些OO功能，但没有任何通用的OO扩展.重要的事情是信息隐藏，失去耦合，可组合性和可测试性，同样，OO不是唯一的做到这一点的方法.

If you want the techniques to scale your project, then OO is not your only friend. While this is probably not a very well explored territory for mma (except may be by WRI), some techniques from other functional languages such as closures, LISP macros, run-time code generation, etc, may well be applicable to mma. For example, one of the mma projects I am working on has more than 40 packages and more than 10 thousand lines of mma code, and it is quite managable (with WorkBench). I am using closures and macros a lot, and also some OO features, but not any generic OO extension. The important things are information hiding, lose coupling, composability and testability, and again, OO is not the only way to do that.

IMO，通过mma中具有OO功能的语言层(也许类似于Python)可以完成的一件非常棒的事情是隐藏评估器和模式匹配器的复杂性，因为在许多情况下，它们并不是需要，可能会使经验不足的用户感到困惑.我曾经(现在仍然)经常缺少这种语言层.这种层的设计者将面临使其与mma其余部分真正集成在一起的艰巨任务.除此之外，我看到在顶级mma中构建的通用OO系统的两个主要障碍:性能低下和没有自动垃圾回收.我认为，在解决这些问题之前，他们会排除在较低级别上大量使用OOP(创建数百万个对象等)的情况. OOP的某些功能对于高级项目体系结构可能仍然非常有用，但是正如我所说的那样，它们很容易实现.这并不是说您不应该尝试使用现有的OO扩展，我只是权衡它们对mma的好处与它们将对您的代码施加的必要限制.

IMO, one very nice thing that could be accomplished by an OO-capable language layer in mma (perhaps, Python-like) would be to hide the complexities of the evaluator and pattern-matcher, because in many cases those are not needed and may be confusing to less experienced users. I was (and still am) missing such language layer quite a bit at times. The designer of such layer will face a hard task of making it really well integrated with the rest of mma. Apart from that, I see the two major obstacles for a generic OO system built in the top-level mma: slow performance and no automatic garbage collection. I think, until these are solved, they rule out the heavy production use of OOP at the lower-level (creating millions of objects etc). Some features of OOP may still be quite useful for high-level project architecture, but as I said, they are easily implemented. This is not to say you should not try existing OO extensions, I'd just weight their benefits specifically for mma against the necessary limitations they will impose on your code.

这篇关于Mathematica OO系统(或替代品)?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！