how to implement OO design using structs?

Hello,

We were looking for a good way to use object oriented design using structs (our client prefers not using classdef). We tried something like this:

 % FooClass.m
 function obj = FooClass(var)

    % Constructor
    obj.var = var;
    obj.Get = @Get;
    obj.Set = @Set;

    % Methods
    function var = Get
        var = obj.var;
    end
    function Set(var)
        obj.var = var;
    end

 end

We found the following behaviour:

 foo = FooClass(1);
 foo.var             % ans = 1
 foo.Get()           % ans = 1
 foo.var = 2;
 foo.Set(42);
 foo.var             % ans = 2
 foo.Get()           % ans = 42

Apparently data members of the struct foo are not linked to the workspace of FooClass, but this workspace stays in scope and can be accessed using foo.Get and foo.Set. Note that if we make a second instance of the class, bar = FooClass(12), then it gets its own FooClass workspace, and foo.Get() and bar.Get() return 42 and 12 respectively. Further note that it also works if we write obj_var instead of obj.var in FooClass.m (this protects from using foo.var).

Is this a reasonable way of doing things? Is this behaviour guaranteed? That is, will each instance of FooClass always get its own workspace, and will it always stay in scope as long as it is used (i.e., methods on the instance being called).

Thanks.

Answer 1

[Adam]

I can't imagine why your client would not want to use classdef, but my own personal advice is that I would strongly advise against trying to create your own OOP behaviour using structs. The whole point of a class is to have methods defined to act on the properties and that you know exactly what is in a class.

A struct is just like a christmas tree to hang anything off and you have no guarantee at any point in your code as to what the fields are on the struct and that some other part of code hasn't added, removed or changed fields that would be private or immutable in a proper class definition.

In your case you are returning a struct out of your function, but structs, in common with other Matlab types other than handle-derived classes, are copied by value, not by reference so if I understand your code correctly your set method is acting on a different internal struct object than that which you call the function on. I may be wrong there, but trying to re-engineer the idea of a class inside a function is such an alien concept to me that it isn't something I have tried myself.

[Johan Meijdam]

Thanks for your input.

I should probably explain that we came up with the idea based on how OO is generally used in C. Although it is not ideal, we can handle the "christmas tree". The thing that bothered us compared to how one would do it in C, is that MATLAB does not allow multiple functions in one file to be accessed from outside that file. Thus, each method would need its own file (FooCreate.m, FooGet.m, FooSet.m, etc.), with the object instance being an input (and when needed also output) of each function.

Maybe, in the end that is the better way of doing things, instead of relying on the function workspace to remain in scope.

[Sean de Wolski]

The statement that each method would need its own file is simply not true for OO or regular MATLAB functions. You can see that the function can pass back handles to local or nested functions which can then be called (like your Get/Set). You cannot call them directly, but you could have all of the local/nested functions passed back as an output (See localfunctions).

I am still confused as to why they don't want classdef. This would be the first thing I would discuss with them.

[Johan Meijdam]

Indeed, I meant it cannot be accessed from outside directly. Which is why we started looking into indirect methods, like your suggestions, and like the example I gave in my original post. There are many options there, but all seem to have their drawbacks, which I guess is why the suggestions keep coming back at: use classdef instead.

Thanks. Your input serves two purposes here: my better understanding of how MATLAB deals with function workspaces, and fuel for the discussion with the client :).

Answer 2

[per isakson]

IIRC: Before R2008a Matlab included support for OOP based on structs. See Classes and Objects: An Overview ( Programming | Classes and Objects ). I believe there are still m-code in Matlab, which use the old OOP-support.

See A Guide to MATLAB Object-Oriented Programming – May 14, 2007 by Andy H. Register - poor timing in hindsight

However, the new OOP-system is superior.

[Johan Meijdam]

An interesting read, thank you. OOP in MATLAB indeed has come a long way with the new system.