Subclassing and Inheritance

Subclassing allows you to build component models based on other component models by extension. Subclassing applies only to component models, not domain models. The syntax for subclassing is based on the MATLAB^® class system syntax for subclassing using the < symbol on the declaration line of the component model:

component MyExtendedComponent < NamespaceName.MyBaseComponent
  % component implementation here
end

By subclassing, the subclass inherits all of the members (such as parameters, variables, nodes) from the base class and can add members of its own. When using the subclass as an external client, all public members of the base class are available. All public and protected members of the base class are available to the events, equation, structure, and other sections of the subclass. The subclass may not declare a member with the same identifier as a public or protected member of the base class.

The setup function of the base class is executed before the setup function of the subclass.

Note

• Starting in R2019a, using setup is not recommended. Other constructs available in Simscape™ language let you achieve the same results without compromising run-time capabilities. For more information, see setup is not recommended.

The equations of both the subclass and the base class are included in the overall system of equations.

For example, you can create the base class ElectricalBranch.ssc, which defines an electrical branch with positive and negative external nodes, initial current and voltage, and relationship between the component variables and nodes (and therefore, connects the component variables with the Through and Across domain variables). Such a component is not very useful as a library block, so if you do not want the base class to appear as a block in a custom library, set the Hidden=true attribute value:

component (Hidden=true) ElectricalBranch
  nodes
    p = foundation.electrical.electrical; % +:left
    n = foundation.electrical.electrical; % +:right
  end
  variables
    i = { 0, 'A' };
    v = { 0, 'V' };
  end
  branches
    i : p.i -> n.i;
  end
  equations
    v == p.v - n.v;
  end
end

If, for example, your base class resides in a namespace named +MyElectrical, then you can define the subclass component Capacitor.ssc as follows:

component Capacitor < MyElectrical.ElectricalBranch
% Ideal Capacitor
  parameters
    c = { 1, 'F' };
  end
  equations
      assert(c>0, 'Capacitance must be greater than zero');	
      i == c * v.der;
  end
end

The subclass component inherits the p and n nodes, the i and v variables with initial values, and the relationship between the component and domain variables from the base class. This way, the Capacitor.ssc file contains only parameters and equations specific to the capacitor.

Overriding Base Class Members in Derived Classes

You can override certain members of base class in derived classes. For example, you can:

• Override the default values of base class parameters

• Override the default initial values, priorities, and other attributes of base class variables

• Override intermediates declared in the base class

• Override annotation attributes declared in the base class, such as Icon or ExternalAccess of base class members

You cannot override the Access attribute of base class members. For example, if a base class member is declared as protected, it stays protected in all derived classes.

You cannot override values or attributes of base class members declared as private.

Annotation override can be conditional, except for annotation types that do not accept conditional definition, such as Side. If the active branch does not explicitly define an annotation override, or if none of the branches are active and an else branch is not explicitly defined, the annotation inherits the attribute from the closest base class in the hierarchy.

In this example, the subclass component Sub:

• Overrides the value of the base class parameter bp1.

• Overrides the value and priority of the base class variable bv1.

• Overrides the base class intermediate bm1.

• Conditionally overrides the block icon and the visibility of the base class parameter bp2 based on the value of the control parameter cp1.

component Base
  parameters
    bp1 = 1;
    bp2 = 2;
  end
  variables
    bv1 = 0;
  end
  intermediates
    bm1 = 2*bv1+bp1;
  end
  annotations
    Icon = 'file1.jpg';
    bp1 : ExternalAccess = modify;
    bp2 : ExternalAccess = observe;
  end  
end
 
component Sub < Base(bp1 = 0.1,...
		     bv1.value = 1.1, ...
		     bv1.priority = priority.high, ...
		     bm1 = 2*bv1+v1+p1)
		     % override base class parameters, variables, intermediates
  parameters
    p1 = 1;
    cp1 = true;
  end
  variables
    v1 = 0;
  end
  if cp1
    annotations
      Icon = 'file2.jpg';            % override the block icon
      bp2 : ExternalAccess = modify; % override bp2 visibility to 'modify'
    end
  else
    annotations
      bp2 : ExternalAccess = none;   % override bp2 visibility to 'none'
    end
  end
  equations
    v1 == 2*p1+bp2
  end
end

Limitations for overriding default values of parameters and variables from the base class:

• You cannot reference other parameters from the base class. For example, when overriding the value of bp1, you cannot reference bp2.

• You cannot reference conditional parameters.

• If the subclass is a composite component, you cannot reference parameters from its member components.

• Parameters used in overriding parameters and variables from the base class cannot be run-time configurable.

These limitations do not apply to intermediates. In the example, parameter p1 can be run-time configurable because it is used in overriding the intermediate bm1. However, if it was overriding the base class parameter bp1 (bp1 = p1), then p1 would be restricted to compile-time only.