Отказ от ответственности: я не использовал ни одно из существующих расширений OO mma (и системы OO в частности), поэтому этот пост основан на общих аргументах (но я интенсивно использовал OO, когда работал в Java, и использовал некоторые элементы OO в мма, которую я реализовал сам). Я согласен с мнением , что ОО является движущейся целью, поэтому вам нужно быть более конкретным с точки зрения функций, которые вы хотите, чтобы получить более полезный ответ. Это также в значительной степени зависит от ваших целей: хотите ли вы упростить свою собственную жизнь и сделать свой собственный масштаб проекта, или вы хотите упростить коммуникацию для проекта, который будет разрабатываться несколькими (многими) разработчиками, и применять определенные правила и протоколы (стандарты кодирования, лучшие практики, шаблоны проектирования и т. д.) или вы хотите, чтобы ОО повторно использовал существующие библиотеки.
Я бы сказал, что большая часть использования ООП в промышленности относится ко второй и третьей категориям. Если это также ваш случай (который я подозреваю, что это не так), то, возможно, имеет смысл использовать ООП в Mathematica, хотя даже это не ясно. Например, WolframAlpha имеет десятки миллионов строк кода в своей кодовой базе, и AFAIK система OO там не использовалась. Если вы хотите получить преимущества для индивидуального разработчика, то я бы выбрал те функции ОО, которые мне нравятся, и реализовал их сам, то есть создал свою собственную объектную модель. Это не так уж сложно в Mathematica.
Было бы гораздо разумнее использовать какое-то конкретное расширение OO Mathematica, если бы существовало большое количество хорошо протестированных библиотек с открытым исходным кодом, созданных с использованием этого расширения, с простым механизмом развертывания. Я не знаю ни о какой существенной базе (библиотеках) mma-кода, созданной с помощью какого-либо из существующих расширений mma OO (что также может быть связано с моим незнанием). Поэтому, если вам необходимо использовать OO для повторного использования существующих библиотек, такие вещи, как J / Link или .Net / Link, могут вам помочь, поскольку у вас будет доступ ко всем Java или .Net.
Если вы хотите, чтобы методы масштабировали ваш проект, то ОО не ваш единственный друг. Хотя это, вероятно, не очень хорошо изученная территория для mma (за исключением, может быть, WRI), некоторые методы из других функциональных языков, таких как замыкания, макросы LISP, генерация кода во время выполнения и т. Д., Вполне могут быть применимы к mma. Например, один из проектов MMA, над которым я работаю, содержит более 40 пакетов и более 10 тысяч строк кода MMA, и он вполне управляем (с WorkBench). Я часто использую замыкания и макросы, а также некоторые функции ОО, но не какое-либо общее расширение ОО. Важными вещами являются сокрытие информации, потеря связи, возможность компоновки и тестируемости, и опять же, ОО не единственный способ сделать это.
IMO, одна очень хорошая вещь, которая может быть реализована с помощью языкового слоя с поддержкой OO в mma (возможно, Python-подобный), состоит в том, чтобы скрыть сложности оценщика и сопоставления с образцом, потому что во многих случаях это не так. необходимо и может сбивать с толку менее опытных пользователей. Я иногда терял (и все еще) пропускаю такой языковой слой. Перед разработчиком такого слоя встанет трудная задача сделать его действительно хорошо интегрированным с остальной частью mma. Кроме того, я вижу два основных препятствия для общей ОО-системы, встроенной в mma верхнего уровня: низкая производительность и отсутствие автоматического сбора мусора. Я думаю, что до тех пор, пока они не будут решены, они исключают интенсивное использование ООП на низком уровне (создание миллионов объектов и т. Д.). Некоторые функции ООП могут все еще быть весьма полезными для высокоуровневой архитектуры проекта, но, как я уже сказал, они легко реализуются. Это не значит, что вы не должны пробовать существующие расширения OO, я просто сопоставлю их преимущества специально для mma с необходимыми ограничениями, которые они наложат на ваш код.