Strategies for Working with Classes Nested within Other Classes?
34 次查看(过去 30 天)
显示 更早的评论
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.
0 个评论
采纳的回答
Daniel Shub
2011-8-15
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.
0 个评论
更多回答(2 个)
Scott
2011-8-16
1 个评论
Daniel Shub
2011-8-17
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.
Nathan Jessurun
2018-7-30
编辑:Nathan Jessurun
2018-7-30
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.
0 个评论
另请参阅
类别
在 Help Center 和 File Exchange 中查找有关 Class Introspection and Metadata 的更多信息
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!