View Categories

What is the purpose of mixins in Dart? Provide an example.

Parthiban Kannan
Updated on December 6, 2025

2 min read

Mixins in Dart are used to reuse code across multiple classes without using traditional inheritance. They let us define a set of methods or properties in one place and then “mix” that functionality into multiple classes — helping to keep code modular, reusable, and DRY (Don’t Repeat Yourself).

Unlike inheritance, where a subclass extends only one superclass, mixins can be applied to any number of classes, making them a powerful tool when you want to share behavior across unrelated classes.

Suppose I have a Flutter app where multiple classes — say Dog and Cat — need the ability to make a sound and move. Instead of duplicating those methods in each class, I can create mixins like this:

📄
filename.dart 
mixin SoundMaker {
  void makeSound(String sound) {
    print('Making sound: $sound');
  }
}

mixin Mover {
  void move() {
    print('Moving...');
  }
}

class Dog with SoundMaker, Mover {
  void bark() => makeSound('Woof!');
}

class Cat with SoundMaker, Mover {
  void meow() => makeSound('Meow!');
}

void main() {
  final dog = Dog();
  dog.bark();
  dog.move();

  final cat = Cat();
  cat.meow();
  cat.move();
}

Here, both Dog and Cat reuse the logic from the SoundMaker and Mover mixins. This avoids duplicate code and keeps behavior modular. If I later want to modify the move() or makeSound() logic, I can do it in one place, and all classes using those mixins automatically get the updated behavior.

I applied this concept in a Flutter project where multiple UI widgets needed common functionalities like logging, analytics tracking, and input validation. Instead of writing those methods in each widget’s class, I created mixins such as LoggerMixin and ValidationMixin. This made the codebase more maintainable and reduced redundancy.

One challenge I faced was when multiple mixins had methods with the same name. Dart resolves such conflicts by using the last mixin in the “with” list, but that can sometimes cause confusion or unexpected behavior. To handle that, I renamed or refactored the methods to make their purpose more explicit.

A limitation of mixins is that they can’t be instantiated on their own — they’re just a collection of methods and properties. Also, mixins can’t have constructors, so they’re best used for behavior, not stateful initialization.

As an alternative, when I need more structured composition with dependencies or state, I sometimes use composition through helper classes instead of mixins — for example, having a Logger class as a property rather than mixing in its methods.

So, in summary, mixins in Dart are a clean and efficient way to share common functionality across multiple classes without deep inheritance hierarchies. They improve code reusability and maintainability, especially when multiple classes need similar behavior but are not related through inheritance.

Scroll to Top