Must dependent properties in abstract class be redefined in every concrete subclass?

I have an abstract superclass that defines some dependent properties, which an object of any concrete subclass should be able to return. Each subclass will have a unique method for deriving the value of each of these properties from its stored data, as implemented by a get.property method.

To do this it appears that I have to replicate the block of dependent properties from the superclass in every subclass. Is this correct? It seems redundant, since the properties are already defined in the superclass.

[Matt J]

No, you don't have to do that. Why do you think so?

[Bruce Elliott]

The initial problem was that I defined the dependent properties in the abstract base class but tried to implement their set/get methods in the concrete subclass without replicating the definitions in the subclass. I then get an error (from the editor - maybe it's not a true error?) saying "The method get.E does not refer to a valid property name."

A web search took me to to this post on stackoverflow from 2012 that quotes an older documention page (the link is broken) that stated, "Concrete subclasses must redefine abstract properties without the Abstract attribute set to true."

Based on that, I replicated the properties identically (they're not declared as abstract in the base class since the entire class is declared to be abstract), and that made the editor errors go away.

EDIT: Just to see if the editor was correct to flag the error, I ran the code without the replicated property definitions, and I do get a run-time errror:

% Cannot specify a get function for property 'Z' in class 'trajectoryECEF', because that property is not defined by that class.

Oddly, that property is the last of 12, and Matlab threw it only for that one, even though the get.Z method is not called by the class constructor. I guess for repeated errors it displays only the last one (???).

Answer 1

[Matt J]

If your abstract base class defines the Dependent property, then its get.property() method must also be defined in the abstract base class. However, the get.property() method can consist of some steps that will be common to all subclasses and some steps that are customized by the subclasses, e.g.,

>> obj=mysubclass;

>> obj.a

This is the get.a of mysubclass

ans =

0.7094 0.6797

0.7547 0.6551

0.2760 0.1626

>> obj.a(:,1)

This is the get.a of mysubclass

ans =

0.1190

0.4984

0.9597

classdef myclass

    properties (Dependent)
     a
    end % methods

    methods
        function val=get.a(obj)

            disp("This is the get.a of "+class(obj))  %common step
            
            val=obj.customizedValues;

        end
    end
    methods (Abstract)
        val=customizedValues(obj)
    end


end % class



classdef mysubclass<myclass


    methods
        function val=customizedValues(obj)

            val=rand(3,2);

        end

    end


end

[Bruce Elliott]

I see how that can work, but it kind of feels like a work-around - would you agree? You've had to define the customizedValues() method just to implement the subclass-specific behavior that you want, which isn't the end of the world, but as I said - it feels like a work-around.

Is there a fundamental reason why the subclasses can't inherit the property definitions from the base class and then have their individual implementations of the require set/get methods? Since copying the dependent property block to the subclasses seems to work, then it seems that inheritance would automatically accomplish the same thing.

On the other hand, if each subclass has to redefine the dependent properties anyway, I'm not sure there's even any reason to define them in the base class at all. ??

[Matt J]

Is there a fundamental reason why the subclasses can't inherit the property definitions from the base class and then have their individual implementations of the require set/get methods?

As I recall, the official MathWorks reason is that making set/get methods overloadable would be prone to errors and conflicts with base class methods. If the parent set method forces a property value to be positive for example, it's supposed to reflect something you can always assume about that property throughout the class hierarchy. If a child class could then relax the requirement that the property value be positive, parent class methods could then fail to support child instances as inputs.

On the other hand, if each subclass has to redefine the dependent properties anyway, I'm not sure there's even any reason to define them in the base class at all. ??

There wouldn't be. You should only define properties and methods in a base class if, as in my example, there is some common feature to them that you want to inherit from the base class

[Bruce Elliott]

Okay, thanks - that seems to make sense, even if I don't fully understand why it has to be this way.

In my case, I don't want to have any implementation of the set/get methods in the base class at all, but I do want to define the properties, since their existence is the thing that is common to all subclasses.

I can imagine, though, that the behind-the-scenes mechanism for connecting dependent properties with their set/get methods might get confused if the definitions are in one (super)class and the methods are in other classes.

I guess I'll just go with replicating the (identical) property definition blocks accross all the classes. It's not pretty, but it works!