Overridden Setter

Documentation Index

Fetch the complete documentation index at: https://docs.syntblaze.com/llms.txt

Use this file to discover all available pages before exploring further.

​

Syntax and Implementation

class SuperClass {
  num _internalState = 0;

  // Base setter declaration
  set configurationValue(num value) {
    _internalState = value;
  }
}

class SubClass extends SuperClass {
  // Overridden setter declaration
  @override
  set configurationValue(num value) {
    // Delegating to the superclass setter
    super.configurationValue = value; 
  }
}

​

Technical Constraints and Rules

1. Signature Matching (Contravariance and Covariance): By default, the parameter type of the overriding setter must be the same as, or a supertype of, the parameter type in the overridden setter. Dart’s sound type system enforces this contravariance to ensure Liskov Substitution Principle (LSP) compliance. However, Dart allows you to intentionally narrow the parameter type (covariance) by using the covariant keyword. If the parameter in the subclass is marked covariant (e.g., set configurationValue(covariant int value)), the compiler permits the narrower type, deferring the type check to runtime.
2. Return Type Declarations: Setters in Dart inherently do not return a value. While it is syntactically valid to explicitly declare a void return type in the setter signature (e.g., void set configurationValue(num value)), the standard Dart linter rule avoid_return_types_on_setters strongly discourages this. The idiomatic approach is to omit the return type entirely.
3. The @override Annotation: While Dart allows overriding without the @override annotation, its use is strictly enforced by standard linting rules. It directs the analyzer to verify that a corresponding setter actually exists in the superclass hierarchy, preventing accidental shadowing if the superclass signature changes.
4. Field to Setter Promotion: In Dart, a standard instance variable implicitly generates a getter and a setter. Therefore, a subclass can override a standard, non-final field from a superclass by explicitly defining a setter. When doing so, the subclass must also override the corresponding getter. If only the setter is overridden, writing to the property updates the subclass’s state, but reading from the property returns the inherited superclass field’s value, leading to disjointed state.

class Base {
  // Implicitly creates a getter and setter backed by a hidden field
  String data = ""; 
}

class Derived extends Base {
  String _internalData = "";

  // Overriding the implicit getter generated by the 'data' field
  @override
  String get data => _internalData;

  // Overriding the implicit setter generated by the 'data' field
  @override
  set data(String value) {
    _internalData = value;
  }
}