I have a lot of friends who come from electrical / physical / mechanical engineering background, and are curious about what is "OOP" all about. They all know Matlab quite well, so they do have basic programming background; but they have a very hard time grasping a complex type system which can benefit from the concepts OOP introduces.

Can anyone propose a way I can try to explain it to them? I'm just not familiar with Matlab myself, so I'm having troubles finding parallels. I think using simple examples like shapes or animals is a bit too abstract for those engineers. So far I've tried using a Matrix interface vs array-based / sparse / whatever implementations, but that didn't work so well, probably because different matrix types are already well-supported in Matlab.

  • 1
    For your benefit, you can assume that matlab is something like C, except it has more diverse libraries, easier documentation, and a slightly different syntax. Commented Apr 19, 2011 at 13:59
  • 3
    If they're curious, what prevents them from googling a bit and reading any brief introduction? I can't imagine a good engineer being genuinely curious about something and not pursuing that interest.
    – user8685
    Commented Apr 19, 2011 at 13:59
  • 2
    @Pear I think the problem is not only the language itself, but the use they make of it. For example, as I understand it, they practically never define new types. Still, that's a good short summary :)
    – Oak
    Commented Apr 19, 2011 at 14:15
  • 4
    Flee! Run away!
    – Job
    Commented Apr 19, 2011 at 14:32
  • 3
    Do not spoil them. They'll be much better off without the useless OOP.
    – SK-logic
    Commented Apr 19, 2011 at 15:34

7 Answers 7


Since 2008, Matlab supports object-oriented programming. So if they want to find out about OOP in a way they're familiar with, they may want to have a look at the Matlab documentation on OOP, especially the examples.

A while ago, I was introducing some of my Matlab-using colleagues to OOP. Here are some examples I used.

Importantly, everything you do with OOP, you can also do otherwise. What OOP allows you is to (1) make more awesome structures, (2) bundle code, and (3) make it easy to modularize code and to program faster.

  1. Structures with fields that automatically update themselves. For example, you store a coordinate in pixels (because you measure it on an image), but for distance calculations, you want to have it in microns. Storing both in a structure is problematic, because if you change one, you must not forget to change the other (and you will). Thus, you choose to store all coordinates in microns, which means that every time you need it in pixels, you have to convert, which is annoying and may be error-prone.
    With an object, you make "coordinate in pixels" a dependent property, the conversion becomes automatic, and you don't have to worry about updating two coordinates at the same time. Of course, you can do much more. For example, your structure could have an 'edit'-method, which pops open a GUI, so that you can easily edit values. Or it can have a save method that is called whenever a value in the structure changes.

  2. You can bundle functions with your data structure. For example, you can have a customized plot function for your data that you call plot(myDataStructure). Similarly, you can have customized disp methods, or even have your data processing methods be attached to your data.

  • I remember from 2008, that the OOP in Matlab was really slow.
    – quant_dev
    Commented Apr 19, 2011 at 19:50
  • @quant_dev: Things are better now (2008 was the first time they offered the feature; there has been some optimization since), though there is still a larger overhead when calling a method of a user-defined object compared to calling a function. If you don't go all-out OOP like you possibly would in C++, but mix OOP and normal functions, where the object acts as the interface between the user and the functions doing the actual work, the system works quite well.
    – Jonas
    Commented Apr 19, 2011 at 21:21
  • While I like your examples, they really aren't that beneficial unless you're looking for major reuse (which is what OOP excels at). If I'm going to be converting from pixels to microns a lot, and haven't used OOP, having a function call microns = convert_to_microns(pixels) will seem just as easy and more familiar than building up some major OOP structuring around class calls. Using the abstraction is great, but with learning OOP in a more procedural setting, there needs to be a strong impetus as to why their thought process should change. Commented Feb 28, 2014 at 20:10
  • I have a serious question. Why that toy in Matlab is called OOP but in C it is not OOP? A C language struct with methods are much more appealing than the ones in Matlab.
    – ar2015
    Commented Sep 14, 2017 at 0:00
  • @ar2015: are you asking why any feature in Matlab is treated as if Matlab were a serious programming language? Or do you believe struct in C have fundamental OOP features Matlab classes lack?
    – Jonas
    Commented Sep 18, 2017 at 17:02

Don't try to find a bridging example. OOP is well-suited in entirely different areas than the 'matlab-style code' is (and vice versa). I would go for the same kind of explanation I would hand to someone who knows a bit about procedural programming but has never worked with structs or similar data structures.


Vectorized MATLAB code has a strongly functional, declarative feel to it, where matrices are frequently viewed as samples in some space, and operations on those matrices as transformations of that space. When a phenomenon, process or entity is modeled using (vectorized) MATLAB, there often exists an explicit numerical representation that operates as an intermediary between the program logic and the conceptual elements of the entity being modeled. As a result, complexities in the problem domain tend to be reflected as numerical complexity, rather than complexity of program logic or control flow.

The Object-Oriented paradigm has a very different feel: It is frequently used in conjunction with a much more direct approach to modelling structural relationships in the world. In many cases, the OO program is a direct model of an entity, where program logic constructs mirror, directly or indirectly, attributes and properties of the system being modeled. As a result of this, OO program logic tends to have more structural "depth" (and possibly complexity), as it reflects more directly the intricacies of the system under test.

Having said that, there are many situations where the Object-Modelling paradigm is very well aligned with the way that a particular problem is understood and described. This is particularly the case when one is attempting to model discrete entities with a more diverse range of attributes and behavior, such that considering each entity individually and in isolation is more informative than considering each property individually, and the entities together as a population.

With OOP you spend time thinking about individual entities and their properties. Collective behavior is harder to visualize & observe. Structures and relationships tend to be expressed explicitly in code.

With vectorized MATLAB, you spend time thinking about populations of entities. Collective behavior is easier to observe. Structures and relationships tend to be expressed implicitly in code.


Most programmers are familiar with one major aspect of object oriented programming, the structure. I would explain that an object is like a structure, but has it's own function calls to deal with the data inside of the structure. Then slowly add in additional details, like inheritance, passing functions along, etc.

  • I tried the "structures with their own functions" approach, and then explaining that depending on the implementation of the structure, the behavior of those functions can changes. That got me a very strong "what is it good for" looks...
    – Oak
    Commented Apr 19, 2011 at 14:17
  • If they are mathematicians, use the word "tuple" instead of "structures".
    – Ingo
    Commented Apr 19, 2011 at 15:14
  • 1
    Matlab doesn't deal in tuples, but... Commented Apr 19, 2011 at 15:33

They all know Matlab quite well

Then it is quite simple : let them try simulink. Simulink models are in OOP spirit. If they understand how to create a simulink model, and if they know how simulink works, then they already know what OO is about.


Matlab is just a language. OOP is the concept.

Try explaining the concepts using a less example driven explanation. Engineers certainly understand different domains and units (ex: adding temperature to distance would be odd), so they should intuitively understand encapsulation and polymorphism without needing concrete examples in Matlab. You should be able to explain abstraction easily enough. Inheritance and composition would be harder to explain without examples, but explain the concept clearly and they should understand.

Generics versus type specificity should be motivated through examples from their math background. Functional programming, passing functions and lambdas are not OOP per se, and that is harder to explain without a more abstract math background that typically presented to engineers (having studied both engineering, software and mathematics, I have some insight into their different specializations).

You might not be able to provide examples using Matlab directly, but you could certainly explain abstraction and encapsulation using examples including structures. Even in languages where you cannot encapsulate your functions (methods) with your data, you can still explain how certain functions are only defined for certain domains.

Considering that many developers value composition over inheritance, you could explain inheritance, composition, and the relative merits of the two.

You could motivate polymorphism in a natural way by reviewing the difference between integers, rationals, reals, and complex numbers, and then explain how the "normal" arithmetic operators are functions (methods), but even though the operator (ex '+') looks the same, it is a different function when used with different domains.

Good Luck!


I am an electrical engineer, but I have more in common with CS programmers than EE programmers. Specifically I have tried, without success, to persuade my fellow students to write at least half-way structured and modular code, let alone object-oriented code.

When I tried to use MATLAB's OO features, I quickly ran into very annoying issues. A method in a class HAS to take an object of that class as its first argument, and HAS to return the object if it's modifying the object. That makes for code like

     function obj_new = modi_object(obj,some_other_data)

and usage like

new_obj = objec.modi_object(some_piece_of_data);

I have almost given up. I suggest you leave them alone, until some decent OO support goes into MATLAB. Ask them instead to give up MATLAB and try to use Python or the like. I am attempting (and failing) to do that.

At the very least, MATLAB OO is in no way a nice gateway to learn OO. You might just put them off for life.

  • why the downvote?
    – Milind R
    Commented Dec 21, 2013 at 8:45
  • I realise this is old, but for what it's worth, the first thing you mention is a feature, and it has to do with dynamic dispatch. The second isn't necessary; if you'd rather mutate the existing object rather than reassign, all you have to do is inherit from the Handle superclass. As for python, I find its implementation of a class much worse / ugly looking than matlab, not sure why you'd say that. Commented Sep 3, 2016 at 18:36

Not the answer you're looking for? Browse other questions tagged or ask your own question.