why can we not modify inherited properties

11 次查看（过去 30 天）
Thomas Michiels
Thomas Michiels 2021-11-17
评论： Thomas Michiels 2021-11-22
I do not understand the design filosofy behind not allowing to redefine properties when inheriting from a parent class.
this has 2 main arguments:
  1. 1when subclassing, you might want to change default values, or access level, as the inheritted class is a specialisation and might handle more concerns than the parent class. the latter is currently impossible while the former would require you to overwrite the default values in the constructor of the object. If this is the intended usecase for default values, setting those default values in the initial class should be blocked, as we now have 2 places to do exactly the same. Conclusion, changing default values for properties should be possible in subclasses.
  2. with the current situation, it is impossible to change a constant property in a subclass, while there might be cases where you don't want a property to change, but it might be different in a different subclass. As it is impossible to look into to future and predict what kind of subclasses might be made based on your class, these restrictions are limitting harsher than what i suspect is intended from a design perspective.
now my question:
can you explain to my why this was implemented (a.k.a. why i shouldn't do what i'm trying to do) in this way, and if there is a future where this might be allowed to change?

请先登录，再回答此问题。

采纳的回答

Matt J
Matt J 2021-11-17
编辑：Matt J 2021-11-17
Well, I'm not a Mathworks developer, but here are my thoughts:
  1. Regarding default values, I believe they must be non-overridable because the super-class constructor is always called before the sub-class constructor is allowed to modify the object. The super-class constructor may depend critically on the original default values to function.
  2. Regarding access levels, a 'private' access designation in the super class specifically means that the developer doesn't want sub-classes to have access to that property. If you allowed a sub-class to unlock access to the property in its own classdef, the notion of 'private' access would be nullified.
  3. It is not immediately clear why you would want to redefine a Constant property. If you wanted it to be changeable, why make it Constant in the first place? Note also that a constant property is not supposed to require an object instance to access it. You access it by typing 'superclassName.propName'. If you're saying you also want to be able to type 'subclassName.propName' and obtain a different value, it is not clear why it is useful to give these properties the same name propName. Accessing the property would still require typing something partially different.
  3 个评论
显示 1更早的评论
Matt J
Matt J 2021-11-17
编辑：Matt J 2021-11-17
is not a good reason to block it globally, as you should then block subclassing in general, becease every getter/setter/method might rely on some conditions
Note that Matlab does not let you overload set.property() and get.property() methods for this very reason.
In any case, a workaround would be to use Dependent properties,
classdef myclass
properties (Dependent)
prop
end
methods
function val=get.prop(obj)
val=get_prop(obj);
end
function val=get_prop(obj)
val=6;
end
end
end
Then, in the subclass, you could just overload get_prop() either to return a different value or forbid access.
classdef mysubclass < myclass
methods
function val=get_prop(obj)
val=5;
% error ('Access forbidden'); %alternative behavior
end
end
end
end
Thomas Michiels
Thomas Michiels 2021-11-22
I don't agree with matlab design choices here, but this is the correct answer, so i will accept this as the solution, thank you very much.

请先登录，再进行评论。

更多回答（0 个）

类别

在 Help Center 和 File Exchange 中查找有关 Subclass Definition 的更多信息

标签

产品


版本

R2021a

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!

Translated by