Polymorphism In Dart

Polymorphism is a fundamental concept in object-oriented programming that allows objects of different classes to be treated as objects of a common superclass. In Dart, polymorphism enables a variable of a superclass type to hold objects of subclasses, allowing for flexibility and extensibility in code design.

What is Polymorphism?

Polymorphism in Dart refers to the ability of different classes to be treated as instances of a common superclass during runtime. This means that a variable of a superclass type can refer to objects of its subclass, allowing for dynamic method binding and flexibility in the design of object-oriented programs.

History/Background

Polymorphism has been a core feature of object-oriented programming languages since their inception. In Dart, polymorphism is supported natively in the language and plays a crucial role in designing scalable and maintainable codebases.

Syntax

class Animal {
  void makeSound() {
    print('Animal makes a sound');
  }
}

class Dog extends Animal {
  @override
  void makeSound() {
    print('Dog barks');
  }
}

void main() {
  Animal myDog = Dog();
  myDog.makeSound();
}

Key Features

• ✅ Allows objects of different classes to be treated as objects of a common superclass.
• ✅ Enables dynamic method binding at runtime.
• ✅ Supports method overriding to provide specific implementations in subclasses.

Example 1: Basic Usage

Example
Copy
class Shape {
  void draw() {
    print('Drawing a shape');
  }
}

class Circle extends Shape {
  @override
  void draw() {
    print('Drawing a circle');
  }
}

void main() {
  Shape myShape = Circle();
  myShape.draw();
}
Try it Yourself

Output:

Drawing a circle

Example 2: Polymorphism with Lists

class Vehicle {
  void drive() {
    print('Vehicle is being driven');
  }
}

class Car extends Vehicle {
  @override
  void drive() {
    print('Car is being driven');
  }
}

void main() {
  List<Vehicle> vehicles = [Vehicle(), Car()];
  
  for (var vehicle in vehicles) {
    vehicle.drive();
  }
}

Output:

Vehicle is being driven
Car is being driven

Comparison Table

Common Mistakes to Avoid

1. Ignoring the Liskov Substitution Principle

Problem: Beginners often create subclasses that do not behave as expected when substituted for their parent class, violating the Liskov Substitution Principle (LSP). This leads to unexpected behaviors in polymorphic code.

// BAD - Don't do this
class Animal {
  String sound() => "Some sound";
}

class Dog extends Animal {
  String sound() => "Bark";
  
  // Incorrectly overrides behavior
  String fetch() => "Fetching!";
}

void makeSound(Animal animal) {
  print(animal.sound());
}

void main() {
  Animal myDog = Dog();
  makeSound(myDog); // Correct usage
  // myDog.fetch(); // This would cause confusion as not all Animals can fetch
}

Solution:

// GOOD - Do this instead
class Animal {
  String sound() => "Some sound";
}

class Dog extends Animal {
  @override
  String sound() => "Bark";
  
  String fetch() => "Fetching!";
}

void makeSound(Animal animal) {
  print(animal.sound());
}

void main() {
  Animal myDog = Dog();
  makeSound(myDog); // Correct usage
}

Why: By ensuring that all subclasses can be used interchangeably with their superclass, you maintain the integrity of polymorphism. Always ensure that subclass behavior is consistent with the superclass.

2. Overuse of Type Checking

Problem: Beginners may rely heavily on type checking (using is or as) instead of leveraging polymorphism, which can lead to fragile and less maintainable code.

// BAD - Don't do this
void makeDogSound(Animal animal) {
  if (animal is Dog) {
    print(animal.sound());
  }
}

Solution:

// GOOD - Do this instead
void makeSound(Animal animal) {
  print(animal.sound());
}

Why: Relying on type checks can lead to code that is hard to maintain and understand. Instead, you should rely on polymorphic behavior, where each class knows how to perform its task without needing to check types.

3. Failing to Override Methods Properly

Problem: Beginners sometimes forget to use the @override annotation when overriding methods, making it harder to catch errors.

// BAD - Don't do this
class Animal {
  void sound() {
    print("Some sound");
  }
}

class Cat extends Animal {
  void sound() { // Missing @override
    print("Meow");
  }
}

Solution:

// GOOD - Do this instead
class Animal {
  void sound() {
    print("Some sound");
  }
}

class Cat extends Animal {
  @override
  void sound() {
    print("Meow");
  }
}

Why: Using @override helps to clearly indicate that a method is intended to override a superclass method. This is essential for code readability and helps the compiler catch mistakes.

4. Not Utilizing Abstract Classes

Problem: Beginners may create concrete classes for base types rather than using abstract classes, which can lead to redundancy and difficulty in managing shared behaviors.

// BAD - Don't do this
class Shape {
  void draw() {
    print("Drawing a shape");
  }
}

class Circle extends Shape {
  void draw() {
    print("Drawing a circle");
  }
}

// Circle is concrete but we don't need an instance of Shape

Solution:

// GOOD - Do this instead
abstract class Shape {
  void draw();
}

class Circle extends Shape {
  @override
  void draw() {
    print("Drawing a circle");
  }
}

Why: Abstract classes define a common interface and allow you to enforce method implementation in subclasses. This leads to cleaner code and better abstraction.

5. Not Understanding the Difference Between Compile-Time and Runtime Polymorphism

Problem: Beginners often confuse compile-time (method overloading) and runtime polymorphism (method overriding), leading to misunderstandings about how polymorphism works.

// BAD - Don't do this
class Printer {
  void print(String message) {
    print(message);
  }
  
  // This is compile-time overload but not polymorphism
  void print(int number) {
    print(number);
  }
}

Solution:

// GOOD - Do this instead
class Printer {
  void printMessage(String message) {
    print(message);
  }
}

class AdvancedPrinter extends Printer {
  @override
  void printMessage(String message) {
    print("Advanced: $message");
  }
}

Why: Understanding the distinction between compile-time and runtime polymorphism helps in designing systems that leverage the power of polymorphism more effectively.

Best Practices

1. Use Abstract Classes for Common Interfaces

Abstract classes allow you to define a contract for your subclasses. By using abstract classes, you can ensure that all subclasses implement the necessary methods.

Why: This leads to a clear and maintainable code structure. Any class that extends the abstract class must implement its methods, ensuring consistency.

2. Favor Composition Over Inheritance

Instead of relying solely on inheritance, consider using composition to achieve polymorphic behavior. This allows for more flexible designs.

Why: Composition can lead to more reusable and easier-to-manage code. It promotes the idea of building classes that can work together rather than being tightly coupled.

3. Document Your Code

Always document your classes and methods, especially when they are intended to be overridden or used polymorphically. Use comments and Dart’s documentation features.

Why: Clear documentation helps other developers (and your future self) understand how to use your classes correctly. It is especially important in polymorphism, where the behavior may not be immediately obvious.

4. Use the `@override` Annotations

Always use the @override annotation when overriding methods. This improves code readability and helps catch errors at compile time.

Why: It makes your intentions clear and helps the compiler catch any discrepancies between the method signatures.

5. Write Unit Tests

Always write unit tests for your polymorphic classes to ensure each subclass behaves as expected. Tests can validate that the correct behavior is maintained when polymorphic methods are called.

Why: This ensures that changes in one class do not inadvertently break the behavior of another. It is crucial for maintaining the integrity of polymorphic behavior in your application.

6. Keep Interfaces Small and Focused

When designing interfaces, ensure they are small and focused on a single responsibility. Avoid large interfaces that require implementing many methods.

Why: Smaller interfaces promote cleaner code and make it easier for classes to implement and extend functionality without being burdened by unnecessary methods.

Key Points