| Products & Services | Solutions | Academia | Support | User Community | Company |
| Download Product Updates | | | Get Pricing | | | Trial Software |
| Documentation → MATLAB |
| Contents | Index |
| Learn more about MATLAB |
| On this page… |
|---|
When you create a subclass derived from multiple classes, the subclass inherits the properties, methods, and events defined by all specified superclasses. If a property, method, or event is defined by more than one superclass, there must be an unambiguous resolution to the multiple definitions. You cannot derive a subclass from any two or more classes that define incompatible class members.
There are a variety of situations where name and definition conflicts can be resolved, as described in the following sections.
If two or more superclasses define a property with the same name, then at least one of the following must be true:
All, or all but one of the properties must have their SetAccess and GetAccess attributes set to private
The properties have the same definition in all super classes (e.g., when all superclasses inherited the property from a common base class)
If two or more superclasses define methods with the same name, then at least one of the following must be true:
The method's Access attribute is set to private so only the defining superclass can access the method.
The method has the same definition in all derived classes. This can occur when all superclasses inherit the method from a common base class and none of the superclasses override the inherited definition.
The subclass redefines the method to disambiguate the multiple definitions across all superclasses. This means the superclass methods must not have their Sealed attribute set to true.
Only one superclass defines the method as Sealed, in which case, the sealed method's definition is adopted by the subclass.
The superclases define the methods as Abstract and rely on the subclass to define the method.
If two or more superclasses define events with the same name, then at least one of the following must be true:
The event's ListenAccess and NotifyAccess attributes must be set to private.
The event has the same definition in all superclasses (e.g., when all superclasses inherited the event from a common base class)
Resolving the potential conflicts involved when defining a subclass from multiple classes often reduces the value of this approach. For example, problems can arise when superclasses are enhanced in future versions and might introduce new conflicts. These potential problems might be reduced if only one superclass is unrestricted and all other superclasses are classes in which all methods are abstract and must be defined by a subclass or inherited from the unrestricted superclass.
In general, when using multiple inheritance, you should ensure that all superclasses remain free of conflicts in definition.
See Defining a Subclass for the syntax used to subclass multiple classes.
MATLAB always calls the most specific subclass constructor first to enable you to call superclass constructors explicitly. Suppose you have a hierarchy of class in which ClassC derives from ClassB, which derives from ClassA:

MATLAB always calls the most specific class constructor (ClassC in this case) first to enable you to control how superclass constructors are called. This enables you to process input arguments and perform any necessary setup before calling the superclass constructors.
If you do not make an explicit call to a superclass constructor from the subclass constructor, MATLAB makes the implicit call before accessing the object. The order is always from most specific to least specific and all the superclass constructors must finish executing before the subclass can access the object.
You can change the order in which class constructors are called by calling superclass constructors explicitly from the subclass constructor.
![]() | Modifying Superclass Methods and Properties | Subclassing MATLAB Built-In Classes | ![]() |

Includes the most popular MATLAB recorded presentations with Q&A sessions led by MATLAB experts.
| © 1984-2009- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |