4

I have had trouble finding help in the matlab documentation and previous questions about using matlab inheritance and class constructors to make an interface. To make it tidy, within a package.

Instead of dragging through my code I can condense it as follows:

A package +MyPkg has a superclass Super and a few subclasses Sub1 Sub2... Most of my properties and methods are defined in Super such that Sub1 and Sub2 really only exist to use their constructors for simple routines or perhaps a few methods overloaded from Super.

So how do I go about writing the classdefs and constructors to support an interface where I can use the following calls:

a = MyPkg.Super(args).Sub1(args)
b = MyPkg.Super(args).Sub1(args).Sub1Method

In this case I want to keep arguments related to Super apart from arguments related to Sub1 for readability and organization.

Questions are welcome.

EDIT:

After considering the accepted answer below and some browsing I reached the conclusion that the interface shown above is not really in the spirit of OO and, for my data analysis application of it a more proper way to approach it would consist of a handle class with a constructor that populates an object or cell array of object properties. Because the class is a handle class one can then use the methods on it to produce desired methods. i.e. the following

% in +MyPkg\

classdef Super < handle
    properties
        outputArray
    end
    methods

    function self = Super(args)
        self.outputArray=load_values(args);
    end

    function out = do_analysis(self,params)
        % do some analysis
    end

    end
end

Then to use this:

data1 = MyPkg.Super(args)
% Populate the outputArray
analysis1 = data1.do_analysis(params)

etc.,

Hope that helps someone else dealing with these issues

St-Ste-Ste-Stephen
  • 1,076
  • 10
  • 19

1 Answers1

2

With respect to your question, you can't if you use inheritance. Only direct superclass constructors can be called from subclasses and only from the subclass can you call the superclass constructor. Ref.

Exposing the superclass like that really breaks the fundamentals of inheritance. Maybe ou should be thinking of another model, maybe composition ("has a" instead of "is a"), if you need that kind of access?

Marc
  • 3,259
  • 4
  • 30
  • 41
  • Thanks for the response, could you explain more what you mean in your last sentence? – St-Ste-Ste-Stephen Jan 24 '12 at 20:41
  • 2
    Sure. Composition is having one object "contain" another. Class1 is held in a property of Class2, and Class2 uses Class1 as a "black box". This is often used to "decorate" a class, i.e. to put a different interface over it. There is a great discussion here: http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance and here:http://lostechies.com/chadmyers/2010/02/13/composition-versus-inheritance/ – Marc Jan 25 '12 at 16:48
  • An ultimate decider I've often used is ask yourself if you need to substitute one class for another at runtime. A good example from GUIs: A simple GUI might have a `Window` parent and two subtypes: `Modal` & `NonModal` dialogs. One could imagine that for drawing on the screen, it has to keep a list of `Windows` and wouldn't care what type they were. If you're using inheritance to share code & functionality, you should probably prefer composition. – Marc Jan 25 '12 at 16:55