Modify attributes of inherited property

4 visualizaciones (últimos 30 días)
Luuk Poort
Luuk Poort el 2 de Nov. de 2021
Comentada: Luuk Poort el 3 de Nov. de 2021
I defined a subclass which inherits a built-in class (mechss) and extends it with some additional properties and methods. Because of my additional properties, the terminology becomes somewhat confusing and I would like to change the property names of the superclass. For example, I would like to change the property C to be called L.
As far as I understand, this is not possible, but I cán define the new property L and relate it to C using get and set methods. This leaves me with two identical properties however, and I would like to hide C and make its access protected.
Is something like this possible?

Respuesta aceptada

Matt J
Matt J el 2 de Nov. de 2021
Editada: Matt J el 2 de Nov. de 2021
Not directly, but you can overload the display() method, customizing it so that C is never displayed at the command line. Similarly, you can customize subsref() and subsasgn() so that dot indexing outside the class does not allow access to C.
  3 comentarios
Matt J
Matt J el 2 de Nov. de 2021
For that matter, if you're overloading these methods, you don't have to create a 2nd property L. You can just customize the display and susbref/subsasgn so that when the alias obj.L is invoked, the value of C is accessed instead.
Luuk Poort
Luuk Poort el 2 de Nov. de 2021
Even better, thank you Matt!

Iniciar sesión para comentar.

Más respuestas (1)

Sean de Wolski
Sean de Wolski el 2 de Nov. de 2021
Editada: Sean de Wolski el 2 de Nov. de 2021
You could instead author your own class that passes through to a mechss object it stores as a private property. Then you can call the properties whatever you want.
  4 comentarios
Sean de Wolski
Sean de Wolski el 2 de Nov. de 2021
The benefit of this approach is if MathWorks changes something in mechss (e.g. overloads indexing which it could), your solution won't break. And it's likely faster than overloading indexing.
Is the main challenge just naming confusion? If yes, maybe consider less confusing names, or names with a pattern/prefix that's easy to distinquish?
E.g., making things up
classdef electromechss < mechss
properties
electroC
electroL
end
methods
electroWhatever1
electroWhatever2
end
end
Luuk Poort
Luuk Poort el 3 de Nov. de 2021
Thank you for both of your input.
So, option 1 is to inherit the mechss class and overload the subsref and subsasgn methods to access the inherited properties with any name I would like, e.g. C can be obtained by .L, while inherited methods can be accessed both with dot notation or function notation.
With option 2, my class is not a subclass, but stores the mechss object as a private property. This is likely faster and more robust to future changes in built-in code. Methods of mechss can be accessed with dot notation by overloading the dot-indexing to be forwarded to the mechss object. To enable function notation, I need to define a new method for each method of mechss to forward it to the mechss object.
I hope I am correct with this and I will test what works out best for me. Unfortunately I cannot accept two answers.
Regarding the naming confusion: I would like object properties to match terminology in my field and in my own documentation to avoid confusion with users, when I will share my implementation in the future.

Iniciar sesión para comentar.

Categorías

Más información sobre Create System Objects en Help Center y File Exchange.

Etiquetas

Productos


Versión

R2021b

Community Treasure Hunt

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

Start Hunting!

Translated by