11

Consider the following simple class hierarchy:

A.m

classdef A < handle
    methods (Access = protected)    %# protected vs. private
        function foo(obj)
            disp('class A')
        end
    end
end

B.m

classdef B < A
    methods (Access = public)
        function foo(obj)
            disp('class B')
        end
    end
end

Class B inherits from class A and is supposed to override the protected foo method as public.

If we try to instantiate the derived class, we get the following error:

>> b=B();
Error using B
Method 'foo' in class 'B' uses different access permissions than its superclass 'A'. 

The weird thing is if foo was defined as private method in the superclass A, the code works just fine when we invoke the overridden method:

>> clear classes
>> b=B(); b.foo()
class B

So is this a limitation/bug in MATLAB OOP implementation, or is there a good reason behind this behavior? (Code was tested on R2012b)


As a comparison, in Java the rules state that you cannot reduce visibility of a method in the sub-class, but you can increase it, where:

(weakest) private < package < protected < public (strongest)
Amro
  • 123,847
  • 25
  • 243
  • 454

1 Answers1

11

This appears to be a limitation of Matlab. I've tried all combinations of attributes. Matlab throws errors whenever the attributes are different, except when the method of A is private, in which case the attributes in B don't matter.

enter image description here

In other words, unless the method in A is private, the attributes of the method in A and B have to be the same. I guess this does make sense to some extent, in that TMW say "If a method is visible to the subclass, attributes have to be the same; if a method is not visible to the subclass, the subclasses can do whatever they like".

Jonas
  • 74,690
  • 10
  • 137
  • 177
  • thanks @Jonas, I had tried all those cases as well.. From a design point of view, I see no reason not to allow overriding methods as such (lower triangle of your figure should be all happy faces!). After all, [Java](http://docs.oracle.com/javase/tutorial/java/IandI/override.html) lets us increase access as I explained before, [C#](http://msdn.microsoft.com/en-us/library/6fawty39%28v=vs.80%29.aspx) offers the `override` and `new` keywords to allow overriding vs. hiding, while [C++](http://stackoverflow.com/q/2671448) have almost no restriction in that regard.. Something to consider MathWorks :) – Amro Nov 19 '12 at 19:19
  • @Amro Yeah, but people realized that C++ is a bit less restricive than it should be, therefore the books on how to do C++ "properly". Note that the smileys in the last row are really nothing to do with inheritance, as B does not see A's private methods. Moreover, if you make A's protected into public, you break A's design constraints, B is no longer an A. – Barney Szabolcs Nov 19 '12 at 19:55
  • @BarnabasSzabolcs: no argument there. As for the last point, I guess the workaround is easy; add a second public method `foo_public` to B that calls its protected `foo` without breaking the inherited interface – Amro Nov 19 '12 at 20:34