Understanding SOLID Principles: Interface Segregation Principle in Dart

Hello, coders! Today, let’s learn about a very important concept in coding known as SOLID principles. Don’t worry, it’s not as hard as it sounds. Just think of it as a set of rules that help us write better and cleaner code.

Today, we’re going to focus on one of these principles. It’s called the Interface Segregation Principle, or ISP for short. It sounds fancy, but it’s quite simple. ISP says that no one should be forced to depend on interfaces they do not use.

What is an Interface?

Imagine you have a toy robot. To control this robot, you have a remote with buttons like ‘move forward’, ‘turn right’, ‘turn left’, ‘beep’ and ‘flash lights’. Each of these buttons is like an interface. When you press ‘move forward’, the robot knows it should move forward.

What Does the Interface Segregation Principle Say?

Now, suppose you have a teddy bear. And, for some reason, we use the same remote to control the teddy bear. But teddy bears can’t move or flash lights. So, those buttons are useless for the teddy bear. This is what ISP wants to avoid. It says that we should not have to worry about the buttons that we do not use.

Case Study: A Flutter Example

Now let’s learn how to apply this principle in Flutter with a simple example.

abstract class Toy {
  void play();
  void move();
  void makeSound();
  void flashLights();
}

class Robot implements Toy {
  @override
  void play() {
    print('Robot: Playing...');
  }

  @override
  void move() {
    print('Robot: Moving...');
  }

  @override
  void makeSound() {
    print('Robot: Beeping...');
  }

  @override
  void flashLights() {
    print('Robot: Flashing lights...');
  }
}

class TeddyBear implements Toy {
  @override
  void play() {
    print('Teddy Bear: Playing...');
  }

  @override
  void move() {
    throw UnimplementedError();
  }

  @override
  void makeSound() {
    throw UnimplementedError();
  }

  @override
  void flashLights() {
    throw UnimplementedError();
  }
}

In this example, both Robot and TeddyBear are implementing the Toy interface. But, the TeddyBear doesn’t need the move(), makeSound(), and flashLights() methods. This violates the ISP because TeddyBear is forced to depend on interfaces that it does not use.

We can fix this by segregating the Toy interface into smaller interfaces.

abstract class Toy {
  void play();
}

abstract class Movable {
  void move();
}

abstract class Soundable {
  void makeSound();
}

abstract class Lightable {
  void flashLights();
}

class Robot implements Toy, Movable, Soundable, Lightable {
  @override
  void play() {
    print('Robot: Playing...');
  }

  @override
  void move() {
    print('Robot: Moving...');
  }

  @override
  void makeSound() {
    print('Robot: Beeping...');
  }

  @override
  void flashLights() {
    print('Robot: Flashing lights...');
  }
}

class TeddyBear implements Toy {
  @override
  void play() {
    print('Teddy Bear: Playing...');
  }
}

Now, TeddyBear only implements the Toy interface, and it doesn't have to worry about move(), makeSound(), and flashLights() anymore. And Robot can still implement all of these interfaces because it needs all of them.

So, that’s the Interface Segregation Principle. It helps our code be more flexible and easier to manage. Remember, it’s like saying, “Don’t force me to use the buttons I don’t need!” And that’s a good rule for coding and for life, isn’t it?

Keep coding and keep having fun! Next time, we’ll learn about another SOLID principle. See you then!