First of all, I belive I should say that I am a newbie on OOP in Matlab, but quite experenced with other languages like C++. So this question may sound like so easy to you but I somehow could not find an explanation to my problem.
Suppose that I have two classes, where the former one is an Abstract class and the latter one is a derived class which is derived from the abstract base class.
You can see an example below.
classdef (Abstract) queue < handle
properties
queue_array = [];
read_index =1;
end
methods
function insert_to_queue (obj, queue_element)
obj.queue_array = [obj.queue_array, queue_element];
end
function clean_queue (obj)
obj.queue_array = [];
obj.read_index = 1;
end
end
end
classdef fifo_queue < queue
properties
end
methods
function get_next_from_queue (obj)
...
end
end
end
Here as you can see, I put the common functions of all the derived classes to the base class for the purpose of code reuse.
However when I try a scrpt like below
f_que = fifo_queue;
f_que.instert_to_queue(some_data); % OK
f_que.clear_queue(); % Error
I got an error like;
No appropriate method, property, or field print for class fifo_queue
Do you have any idea of why I face with this type of behaviour on MATLAB?
Thanks
Related
In Matlab (2017b) I'm trying to implement a superclass with a yet undefined abstract property.
classdef Class_Test1
properties (Abstract=true)
obj
end
end
Subclasses should then implement this property and restrict it to a certain class, e.g.:
classdef Class_Test2 < Class_Test1
properties
obj#double = 123;
end
end
a = Class_Test2; now throws an error:
The property 'obj' restriction defined in class 'Class_Test2' must match
the property definition in base class 'Class_Test1'.
Is there no way to specify the class / type of obj in the implementation of the abstract class or am I missing something?
In the end I would like obj to be abstract in Class_Test1 to implement several subclasses, which will hold objects of different classes in obj.
Any help appreciated ...
MATLAB classes are weird... or in any case very different from what you expect from a class if you've learnt about classes in any other programming language.
One aspect of MATLAB is that it's an interpreted language. Stuff is evaluated when executed, not when compiled. So code doesn't always need to make sense.
So, we can solve your issue like this:
classdef (Abstract) foo
methods
function c = getclass(in)
c = class(in.obj);
end
end
end
The function foo.getclass seems to not make sense, since foo doesn't have a property obj. But because foo is abstract, we're never going to have an object of class foo on which we'll call the getclass method. Whenever getclass is called, it'll be a derived class. So, if we want to use this getclass method, we need to make sure that the derived class has a property obj:
classdef foo_uint8 < foo
properties
obj#uint8 = uint8(1);
end
end
It is now possible to call foo_uint8.getclass:
>> a = foo_uint8;
>> a.getclass
ans =
'uint8'
OK, so after looking into this further it seems that this is a deliberate limitation based on the design of Matlab. I'm not too familiar with OOP in other languages but would be interested to learn if this is an general OOP fundamental or rather Matlab specific.
As a workaround I have come up with the following solution:
classdef (Abstract) Class_Test1 < handle
properties
Obj
end
properties (Abstract = true, Constant)
ObjClass#char
end
methods
function set.Obj(obj_in,in)
if isa(in, obj.ObjClass)
obj_in.Obj = in;
end
end
end
end
... and the implementation ...
classdef Class_Test2 < Class_Test1
properties (Constant)
ObjClass#char = 'double'; % Define the allowed class here ...
end
end
I would still be interested to learn about other possible solutions.
i have this superClass
classdef SysSignal<handle
%SIGNALP Summary of this class goes here
% Detailed explanation goes here
properties (SetAccess = public, GetAccess = public )
SetOfSignal = containers.Map('KeyType','char', 'ValueType', 'any')
end
methods
%constructor
function sys=SysSignal()
end
function sys=adds(sys,varargin)
%convert form cell to signalup
for n=1:length(varargin)
signal=varargin{1,n};
if isempty(signal.name)
continue
else
%add to the map
sys.SetOfSignal(signal.name)= signal;
end
end
end
and that child class
classdef Signalp<SysSignal
%SIGNALP Summary of this class goes here
% Detailed explanation goes here
properties
name
lineNo
color='red'
sumrole
end
properties (SetAccess=private,GetAccess=public)
arrPrice
LineLength
LineProportion
end
methods
%constructor
function sig=Signalp(varargin)
end
end
end
now i want to change the properties like this:
sys=SysSignal;
s=Signalp;
s.name='dd';
sys.adds(s)
sys.SetOfSignal('dd').sumrole='hello'
but i get that error :
??? Error using ==> subsasgn
Only one level of indexing is supported by a containers.Map.
how can i change the values from the superClass?
The answer is to seperate sys.SetOfSignal('dd').sumrole='hello' into two statements:
dd = sys.SetOfSignal('dd');
dd.sumrole='hello'
That is because sys.SetOfSignal('dd').sumrole doesn't do what you'd intuitively think it does. Indeed the containers.Map class overloads the subscripted reference and subscripted assignment operators. In essence they 'intercepts' the (), {} and . operators at the same time (ie .sumrole is 'sent' to the map.Containers object - instead of your object!). In my opinion that's a really weird design decision but we must live with it!
Have a look at these links for more info:
subsref, subsasgn
gregswiss's answer is correct, except that accessing the containers map creates a copy, so you finish by replacing the old value with the new modified one
dd = sys.SetOfSignal('dd');
dd.sumrole='hello'
sys.SetOfSignal('dd') = dd;
I come from a Java background. I am having issues with classes in Matlab particularly getters and setters. getting a message saying conflict between handle and value class I'm a little lost with what to do so any help for lack of a better word will be helpful.
classdef Person
properties(Access = private)
name;
age;
end
methods
% class constructor
function obj = Person(age,name)
obj.age = age;
obj.name = name;
end
%getters
function name = get.name(obj)
end
function age = get.age(obj)
end
%setters
function value = set.name(obj,name)
end
function value = set.age(obj,age)
end
end
end
Implementation
Since your class is currently a subclass of the default Value class, your setters need to return the modified object:
function obj = set.name(obj,name)
end
function obj = set.age(obj,age)
end
From the documention: "If you pass [a value class] to a function, the function must return the modified object." And in particular: "In value classes, methods ... that modify the object must return a modified object to copy over the existing object variable".
Handle classes (classdef Person < handle) do not need to return the modified object (like returning void):
function [] = set.name(obj,name)
end
function [] = set.age(obj,age)
end
Value vs. Handle
Going a bit deeper, the difference between a Value class and a Handle class lies mostly in assignment:
Assigning a Value class instance to a variable creates a copy of that class.
Assigning a Handle class instance to a variable create a reference (alias) to that instance.
The Mathworks has a good rundown on this topic.
To paraphrase their illustration, the behavior of a Value class is
% p is an instance of Polynomial
p = Polynomial();
% p2 is also an instance of Polynomial with p's state at assignment
p2 = p;
and of a Handle class is
% db is an instance of Database
db = Database();
% db2 is a reference to the db instance
db2 = db;
Quick'n Dirty from the Java perspective:
- "handle" classes are what your mind is set to. proper object instances with pointers to them. use them.
- "value" classes are always returning a full clone of whatever object (which has been modified by what you just did, e.g. setting a name).
the reason they have both in Matlab is that in Matlab you would expect the "value" behaviour natively. Imagine you have a matrix A = [1 2; 3 4], then assign that via B = A. if you now set B(1) = -1 you'd hope that A(1) is still 1, right? this is because matlab keeps track of "copies" and truly creates them as you modify different variables initially set to the same matrix. in OOP you'd have A(1)=-1 now as everythings an object reference.
furthermore, "native" matlab routines dont have a "this/self/me" variable that contains the instance reference to access from within functions. instead, the convention is that the class instance will be prepended to the function's argument list.
so for a function call myclass.mymethod(arg1,arg1), the declaration must be
function mymethod(this, arg1, arg2)
% Note that the name you choose for "this" is arbitrary!
end
mind you, this is the java-perspective (and also my favourite one), the above function call is equivalent to mymethod(myclass,arg1,arg1). this is more native to matlab-style, but somehow makes it harder to see you're calling an objects method.
now, regarding setters/getters: for handle classes, everything feels java-ish now:
classdef MyClass < handle
properties
MyProp;
end
methods
function set.MyProp(this, value) %Note: setMyProp is also valid!
... % do checks etc, trigger calls,
this.MyProp = value;
end
function value = get.MyProp(this)
... % notify, update, triggers etc
value = this.MyProp;
end
end
Of course it goes without saying that you dont need to define a getter if you just want to return the value, i.e. myclassinstance.MyProp will work without any just as well.
Finally, getters/setters for value classes are something that [never encountered me/i never needed] in my 7 years of matlab oop, so my advise would be to go with handle classes and enjoy happy matlab coding :-)
otherwise, the above explanation & official matlab docs is doing the job for value class getter/setters.
I'd like to customize the display of an enumeration class using matlab.mixin.CustomDisplay.
If I have a regular (non-enumeration) class such as the following:
classdef test < handle & matlab.mixin.CustomDisplay
properties
value
end
methods
function obj = test(value)
obj.value = value;
end
end
methods (Access = protected)
function displayScalarObject(obj)
disp(['hello ', num2str(obj.value)])
end
end
end
then everything works fine - for example,
>> a = test(1)
a =
hello 1
But if I have an enumeration class such as the following (note the addition of the enumeration block):
classdef test < handle & matlab.mixin.CustomDisplay
properties
value
end
methods
function obj = test(value)
obj.value = value;
end
end
methods (Access = protected)
function displayScalarObject(obj)
disp(['hello ', num2str(obj.value)])
end
end
enumeration
enum1(1)
end
end
then the display is not customized - for example,
>> a = test.enum1
a =
enum1
Using the debugger, I can see that my displayScalarObject method is never called. Implementing other methods of matlab.mixin.CustomDisplay such as displayNonScalarObject and so on doesn't seem to help - these never get called either.
What's going on? Do disp and display work differently for enumeration classes, in such a way that anything that's overridden by matlab.mixin.CustomDisplay just gets ignored?
Is there a way to get a customized display with matlab.mixin.CustomDisplay, but using an enumeration class?
PS I am able to directly overload disp and/or display on an enumeration class that does not inherit from matlab.mixin.CustomDisplay, and this works fine. But I'm looking to use matlab.mixin.CustomDisplay if possible.
I'll answer my own question in case anyone else is interested.
The question was asked with reference to MATLAB R2014a. In R2014b, an additional note has been added to the documentation for matlab.mixin.CustomDisplay, making it explicit that it is not possible to use matlab.mixin.CustomDisplay to derive a custom display for enumeration classes, and suggesting that the best approach is to overload disp.
Is there a way to define static member variables in MATLAB classes?
This doesn't work:
classdef A
properties ( Static )
m = 0;
end
end
It suggests to use keyword "Constant" instead of "Static", the constant properties cannot be modified. I want a variable common to all objects of class A and I want to be able to modify that variable in methods of class A.
So what I need is a private static member variable. Is there a way to obtain it in MATLAB?
Found out that a workaround can be done using persistent variables in static member functions.
In this case you should inherit all your classes from a base class like the following.
classdef object < handle
properties ( GetAccess = 'public', SetAccess = 'private' )
id
end
methods ( Access = 'protected' )
function obj = object()
obj.id = object.increment();
end
end
methods ( Static, Access = 'private' )
function result = increment()
persistent stamp;
if isempty( stamp )
stamp = 0;
end
stamp = stamp + uint32(1);
result = stamp;
end
end
end
You can not, it is by design. You should use a persistent variable (technique from the MATLAB as 1980 applied in year 2011)!
For completeness I should mention that actually there is as of 2010b an undocumented and probably not longer supported static property modifier.
For background see here the answer of Dave Foti, MATLAB OO group manager:
In MATLAB, classes can define Constant
properties, but not "static"
properties in the sense of other
languages like C++. There were beta
releases that experimented with
"Static" properties and the
undocumented attribute remains from
then. However, the Static attribute is
undocumented, should not be used, and
will likely be removed in a future
MATLAB release. R2008a implements it
as a synonym for Constant and provides
no additional functionality beyond
the documented behavior of Constant
properties.
Constant properties may not be changed
from the initial value specified in
the property declaration. There are a
couple of reasons why MATLAB works
the way it does. First, MATLAB has
longstanding rules that variables
always take precedent over the names
of functions and classes and that
assignment statements introduce a
variable if one doesn't already exist.
Thus, any expression of the form "A.B
= C" will introduce a new variable A that is a struct array containing a
field B whose value is C. If "A.B = C"
could refer to a static property of
class A, then class A would take
precedent over variable A and this
would be a very significant
incompatibility with prior releases
of MATLAB. It would mean that an
m-file containing the assignment
statement "A.B = C" could have its
meaning changed by the introduction
of a class named A somewhere on the
MATLAB path. MATLAB programmers have
always been able to rely on assignment
statements introducing variables that
shadow any other use of the same name.
Second, we have observed that static
data is rarely used in other classes
except as private data within the
class or as public constants. For
example, a survey of several Java
class libraries found that all public
static fields were also final. In
MATLAB, Constant properties can be
used like "public final static"
fields in Java. For data internal to a
class, MATLAB already has persistent
variables that can be created inside
of private or protected methods or
local functions privately used by a
class. There are also good reasons to
avoid static data in MATLAB where
possible. If a class has static data,
it can be difficult to use the same
class in multiple applications
because the static data can be a
source of conflicts among
applications. In some other languages,
this is less of an issue because
different applications are separately
compiled into executables running in
different processes with different
copies of class static data. In
MATLAB, frequently many different
applications may be running in the
same process and environment with a
single copy of each class.
Here's a direct way to create a static property in Matlab. The only difference between this implementation and a hypothetical (but impossible; see Mikhail's answer) true static property is the syntax for setting the member variable.
classdef StaticVarClass
methods (Static = true)
function val = staticVar(newval)
persistent currentval;
if nargin >= 1
currentval = newval;
end
val = currentval;
end
end
end
Now the static property staticVar can be read via:
StaticVarClass.staticVar
...and be set via:
StaticVarClass.staticVar(newval);
So, for instance, this is the expected output from a test of this functionality:
>> StaticVarClass.staticVar
ans =
[]
>> StaticVarClass.staticVar('foobar')
ans =
foobar
>> StaticVarClass.staticVar
ans =
foobar
>>
This approach works just as well for private static properties like you requested, but the demo code is a little longer. Note that this is not a handle class (though it would work perfectly well on a handle class as well).
classdef StaticVarClass
methods (Access = private, Static = true)
function val = staticVar(newval)
persistent currentval;
if nargin >= 1
currentval = newval;
end
val = currentval;
end
end
methods
function this = setStatic(this, newval)
StaticVarClass.staticVar(newval);
end
function v = getStatic(this)
v = StaticVarClass.staticVar;
end
end
end
...and the test:
>> x = StaticVarClass
x =
StaticVarClass with no properties.
Methods
>> x.getStatic
ans =
[]
>> x.setStatic('foobar')
ans =
StaticVarClass with no properties.
Methods
>> x.getStatic
ans =
foobar
>>
(just to inform)
there is (another?) way to create static-like data in matlab
suppose that you have a "handle" class which its name is "car"
if you want the car class to have static data, you could construct another handle class and use it in car class throw composition, the latter class works as a static data for car class
classdef car<handle
properties
static_data:STATIC_DATA_HOLDER;
end
end
classdef STATIC_DATA_HOLDER<handle
properties
data
end
end
this way when you create first instance of a car class, an instance of STATIC_DATA_HOLDER will be created and when you create second instance of car class it uses previously created STATIC_DATA_HOLDER class.
these code tested with "MATLAB 2013b"
Another workaround to get something like static properties is to use the fact that initialisation code for member variables is only executed once when the class file is loaded. That means, if you have a definition like
classdef foo
properties
stuff = some_function()
end
end
then some_function is invoked only once, and if it returns an object of class type, this will be shared by all instances. I've added a sample implementation that shows how that can be used:
classdef ClassWithStaticMembers
properties
classvars = StaticVarContainer('foo', 0, 'bar', 2);
othervar
end
methods
function obj=ClassWithStaticMembers(var)
obj.othervar = var;
end
end
end
classdef StaticVarContainer < dynamicprops
methods
function obj=StaticVarContainer(varargin)
for i=1:2:numel(varargin)
obj.addprop(varargin{i});
obj.(varargin{i}) = varargin{i+1};
end
end
end
end
If you run this sample code
obj1 = ClassWithStaticMembers(3);
obj2 = ClassWithStaticMembers(5);
obj1.classvars.foo = [2,3];
obj1.othervar
obj1.classvars
obj2.othervar
obj2.classvars
you'll see, that classvars is indeed shared. I think this solution is much nicer than using persistent variables in functions, since you can reuse the StaticVarContainer as often as you want, it's easier to use, and furthermore, you directly see the initialisation of the static variables in the properties section.
To get the result, that is desired in the OP's question (i.e. implementing an object counter) the shared property can be made Constant, so that it can be referenced without an instance at hand:
classdef ClassWithCounter
properties (Constant)
static = StaticVarContainer('counter', 0);
end
methods
function obj=ClassWithCounter()
obj.static.counter = obj.static.counter + 1;
end
end
end
clear all
obj1 = ClassWithCounter();
obj2 = ClassWithCounter();
obj3 = ClassWithCounter();
ClassWithCounter.static.counter
Note, that the Constant attribute only means that, e.g. obj1.static cannot be changed, but it does not affect obj1.static.counter which is not constant, and can be set to heart's desire.