Hello, I am progressing slowly in this direction. I confirm that the Wolfram language already has a standard object model: Options. I am wondering what kind of relationship between objects the FilterRules (formerly FilterOptions) system installs . I think it is heritage.

Maeder's paper is still up to date after 27 years.

An example of object oriented programming in Mathematica is notebook programming.

Notebook attributes can be edited with the option inspector.

Notebook style follows a class organization. Instancing works by choosing style, in front end menu Format > Edit style sheet. Subclass creation works by editing a style sheet.

Before associations, options are already a good support of object oriented programming. They are extensively used for graphics objects.

The problem of OOP in Mathematica is some sort of contradiction with functional programming. In functional programming, we don't like hidden or private states and side effects but they are necessary for graphics and useful for notebooks, because our generally slow brains perceive those illusive objects so fast.

Lisp is another functional language that has developed an object system, see Common Lisp Object System on Wikipedia. At first sight, it looks familiar, like pattern matching. The same path in Mathematica seems possible.

The answer to this is to use Object-Oriented Design Patterns in Mathematica as explained and exemplified in the blog post "Object-Oriented Design Patterns in Mathematica".

There is a related presentation "Object Oriented Design Patterns" at the Wolfram Technology Conference 2015. (The presentation recording is also uploaded at YouTube.)

Here is a link to a PDF document describing how to implement OOP Design Patterns in Mathematica:

"Implementation of Object-Oriented Programming Design Patterns in Mathematica"

The described approach does not require the use of preliminary implementations, packages, or extra code.

Design Patterns brought OOP into maturity. Design Patterns help overcome limitations of programming languages, give higher level abstractions for program design, and provide design transformation guidance. Because of this it is much better to emulate OOP in Mathematica through Design Patterns than through emulation of OOP objects. (The latter is done in all other approaches and projects I have seen.)

Related posts/descriptions/answers

1. Blog post "Object-Oriented Design Patterns in Mathematica".

2. Blog post "UML diagrams creation and generation", available also on Community.

3. This answer in the MSE discussion General strategies to write big code in Mathematica?.

4. This answer in the MSE discussion Can one identify the design patterns of Mathematica?.

5. This answer to the MSE question "Import and Plot Git Commit history" that has two implementations, one functional and one object oriented.

I've published recently a package that allows to do object oriented programming in Mathematica 10.

You can find it on github at https://github.com/faysou/MTools .

Any comments or ideas of improvement are welcome.

Thanks everyone for your responses. Its been quite illuminating.

I have been working with Mathematica for more than a decade. There is always more to learn it seems.

Could you post a short example of the functionality you described?

Take a look here:

• http://mathematica.stackexchange.com/questions/tagged/object-oriented?sort=votes&pageSize=50

Yes Venkat, We have an excellent book from R.E.Maeder (who was a Mathematica programmer at the beginning with Stephen. "Programming in Mathematica/The Mathematica programmer". A bit out-dated but just excellent. Regards, JMC