Замяна на методи на суперклас и модификатори за достъп в MATLAB

Помислете за следната проста йерархия на класовете:

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

Клас B наследява от клас A и се предполага, че замества защитения foo метод като публичен.

Ако се опитаме да инстанцираме производния клас, получаваме следната грешка:

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

Странното е, че ако foo е дефиниран като частен метод в суперкласа A, кодът работи добре, когато извикаме заменения метод:

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

И така, това ограничение/бъг в изпълнението на MATLAB OOP ли е или има добра причина зад това поведение? (Кодът е тестван на R2012b)


За сравнение, в Java правилата гласят, че не можете да намалите видимостта на метод в подкласа, но можете да я увеличите, където:

(weakest) private < package < protected < public (strongest)

person Amro    schedule 19.11.2012    source източник
comment
Свързвали ли сте се с TMW за това? Изглежда като бъг...   -  person Rody Oldenhuis    schedule 19.11.2012
comment
@RodyOldenhuis: все още не, не съм сигурен дали това е грешка или избор на дизайн от MathWorks..   -  person Amro    schedule 19.11.2012


Отговори (1)


Това изглежда е ограничение на Matlab. Опитах всички комбинации от атрибути. Matlab хвърля грешки винаги, когато атрибутите са различни, освен когато методът на A е частен, в който случай атрибутите в B нямат значение.

въведете описание на изображението тук

С други думи, освен ако методът в A не е частен, атрибутите на метода в A и B трябва да бъдат еднакви. Предполагам, че това има смисъл до известна степен, тъй като TMW казва "Ако даден метод е видим за подкласа, атрибутите трябва да са еднакви; ако методът не е видим за подкласа, подкласовете могат да правят каквото си искат".

person Jonas    schedule 19.11.2012
comment
благодаря @Jonas, аз също бях изпробвал всички тези случаи.. От гледна точка на дизайна не виждам причина да не разрешавам приоритетни методи като такива (долният триъгълник на вашата фигура трябва да е изцяло щастлив!). В крайна сметка Java ни позволява да увеличим достъпа, както обясних преди , C# предлага override и new ключови думи, които позволяват замяна срещу скриване, докато C++ няма почти никакви ограничения в това отношение.. Нещо, което трябва да вземете предвид MathWorks :) - person Amro; 19.11.2012
comment
@Amro Да, но хората разбраха, че C++ е малко по-малко ограничаващ, отколкото трябва да бъде, затова книгите за това как да правите C++ правилно. Обърнете внимание, че усмивките в последния ред наистина нямат нищо общо с наследяването, тъй като B не вижда личните методи на A. Нещо повече, ако направите A защитено публично, вие нарушавате ограниченията на дизайна на A, B вече не е A. - person Barney Szabolcs; 19.11.2012
comment
@BarnabasSzabolcs: няма аргумент. Що се отнася до последната точка, предполагам, че решението е лесно; добавете втори публичен метод foo_public към B, който извиква своя защитен foo, без да нарушава наследения интерфейс - person Amro; 20.11.2012