Strategies for Working with Classes Nested within Other Classes?

I'm trying to define a class that is composed of several other classes but I'm having trouble getting the functionality that I'd like.

As a hopefully sufficiently generic example, assume that I have defined a transimission class and an engine class to represent, respectively, transmission and engine objects. The tranmission class definition might include:

properties
  numGears
  gearRatios
  totalMass
end

The engine class definition might include:

properties
  numCylinders
  totalMass
end

In addtion, the transmission class defintion might also include a method that returns the gear ratio for a selected gear:

methods
  function ratio = transRatio(transmissionObj, gearNum)
    <function body>
  end
end

Having defined those classes, I now seek to define a driveTrain class that includes both a transmission and an engine object:

properties
  transmissionObj
  engineObj
  otherStuff
end

One could imagine defining a method for this driveTrain class that yields the total mass.

methods
  function mass = totalMass(driveTrainObj)
    mass = driveTrainObj.transmissionObj.totalMass + driveTrainObj.engineObj.totalMass;
  end
end

Simple enough, right? But what if a user wants to set/get the number of cylinders in a driveTrain object? They could manually "drill down" to the engine obect which requires that they know which nested object "numCylinders" is stored in (e.g. cylinders = driveTrainObj.engineObj.numCylinders). Alternatively, we could add a numCylinders property to the driveTrain class definition and then define set/get methods that would automatically "drill down" to the correct nested object so that the nested objects are effectively invisible to the user (i.e., so that the user could simply call cylinders = driveTrainObj.numCylinders).

The second technique works fairly well since all set/get functions of this type would have an identical form (so they would be easy to define for dozens of nested properties), but what if one wants to call a method like transRatio that was originally defined within one of the nested classes? Again, the user could manually drill down to the nested object method via ratio = driveTrainObj.transmissionObj.transRatio(gearNum) but that means that the nested classes aren't invisible to the user.

I could also try defining duplicate methods within the driveTrain class for each nested method, but that's not desirable for several reasons. First, if I fully re-define the method then I've negated the whole purpose of leveraging existing classes (not to mention this makes updating the code more difficult since identical code will be in mulitple locations).

Second, if I create "wrapper" methods within the top level class that simply pass the arguments to the nested class methods then I think I need to explicitly account for the possibility of different numbers of input and output arguments for each nested method by parsing the arguments in the top level method and then explicitly calling different forms of the nested methods (again, this would make revising these methods messy because I'd have to ensure that the top level methods continue to track the nested method call syntax). As far as I know, there's not a way to simply say "if a user calls THIS top level method he really means THAT nested method".

I freely admit that I'm not familiar with all of the ways that you can work with classes. Am I going about this the wrong way? Should I be thinking about constructing these classes in a different way to accomplish what I need? Is what I'm seeking to do unrealistic?

Of course, this is just an example. In reality, the classes would have many more properties and methods as well as more complex methods.

Thanks in advance for any wisdom you might offer.

Answer 1

[Daniel Shub]

I think you can get around your this with subsref. Consider the call:

[A, B, C, ...] = driveTrainObj.transRatio(a, b, c, ...)

The first element in the substruct S that is passed to subsref will have type "." and subs "transRatio". You can then call

if strcmp(S(1).type, '.') && strcmp(S(1).subs, 'transRatio')
  [varargout{1:nargout}] = driveTrainObj.transmissionObj.(S(1).subs)(S(2:end));
else
  [varargout{1:nargout}] = builtin('subsref', obj, S);
end

You can do more complicated catching and sorting to figure out what method to call. In general, you also should not call the builtin subsref, but rather work your way up any class tree. Something more like:

[varargout{1:nargout}] = subsref@superclass(obj, S);

This, however, requires your superclass to have a subsref method.

Answer 2

[Scott]

Daniel,

Thanks for the suggestion--it really put me on the right track. BUILTIN doesn't support user functions so I used FEVAL instead. Defining a method in the superclass for each nested function of interest then becomes straight forward (no use of SUBSREF required):

function varargout = nestedFun(obj, varargin)
  varargout{1:nargout} = feval('nestedFun', obj.nestedClass, varargin{:});
end

Nice and simple. Thanks again!

[Daniel Shub]

Look at my answer again, I only use builtin on subsref. I suggested using the transRatio method of the transmissionObj. I don't know if the JIT compiler handles my case better than feval, but it might. From a code maintenance standpoint, you might want to think about:

[varargout{1:nargout}] = obj.nestedClass.nestedFun(varargin{:});

I also think the brackets on the LHS are important if nargout is > 1, but I could be wrong.

Answer 3

[Nathan Jessurun]

A bit late, but giving the outer class handles instead of functions might suit your purpose. For instance, instead of the function

 function outerAccessToInnerMethod
   % Call to inner using feval, etc.
 end

You can set a constant function handle to the inner function:

 properties (Constant)
   outerAccessToInnerMethod = @nested.innerMethod;
 end

That way all calls to outerAccessToInnerMethod will 'drill down' for you, and you don't have to worry about dynamically accounting for inputs or outputs.

The only downside is this won't show up as a method to the outer class, but I found that to be an acceptable loss in my application.