SOLID Principles In Flutter

Flutter has gained immense popularity among mobile app developers due to its ability to create cross-platform applications efficiently. To build robust, maintainable, and scalable Flutter applications, developers need to follow best practices and design patterns. One such set of principles that can significantly enhance the quality of your codebase is SOLID.

You can also read more about Flutter app development services from Mobikul.

SOLID stands for Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, which we will discuss in the following sections. Let’s check how can we implement SOLID Principles in flutter.

Single Responsibility Principle:

This principle says that a class should have a single responsibility (i.e. only one potential change in the software’s specification should be able to affect the specification of the class). When it comes to flutter development, adhering to SRP ensures that each widget or class is focused on doing one specific task.

For example, suppose you have a widget responsible for displaying user information and handling user interactions. Instead of combining both functionalities in a single widget, it is better to create separate widgets for displaying information and handling user interactions. This way, you keep the responsibilities distinct and the code more organized.

Open/Closed Principle :

The Open/Closed Principle suggests that software entities (classes, modules, functions) should be open for extension but closed for modification. In Flutter development, this principle promotes the use of inheritance and composition to add new features without altering existing code.

Suppose we have different departments checking their exam result. Let’s check bad practice first:

class ExamResult
{
  mechanicalCheckResult()
  {
    // some code 
  }

  civilCheckResult()
  {
    // some code 
  }

}

class ExamResult

{

mechanicalCheckResult()

{

// some code

}

civilCheckResult()

{

// some code

}

After applying Open- Closed Principle:

abstract class ExamResult {
  checkResult();
}

class ComputerScience implements ExamResult {
  @override
  checkResult() {
    // some code
  }
}

class Civil implements ExamResult {
  @override
  checkResult() {
    // some code
  }
}

class Mechanical implements ExamResult {
  @override
  checkResult() {
    // some code
  }
}

abstract class ExamResult {

checkResult();

}

class ComputerScience implements ExamResult {

@override

checkResult() {

// some code

}

class Civil implements ExamResult {

@override

checkResult() {

// some code

}

class Mechanical implements ExamResult {

@override

checkResult() {

// some code

}

Liskov Substitution Principle :

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of its subclasses without affecting the correctness of the program. In simpler terms, if a class implements an interface, any subclass should be able to replace the parent class and work seamlessly with existing code.

For instance, if you have an abstract Widget class with some common functionality, its subclasses should be able to replace the Widget class without causing any issues in the application.

Interface Segregation Principle:

This principle states that no client should be forced to depend on a method it doesn’t use. According to this principle, clients don’t need to implement behaviors they don’t want. As a general rule, you should create small interfaces with few methods.

This is the first principle that applies to an interface; the other three principles apply to classes.

Let’s check an example:

abstract class Teacher{
  void work();
  void sleep();
}
class Human implements Teacher{
  void work() => print("I do a lot of work");
  void sleep() => print("I need 10 hours per night...");
}
class Robot implements Teacher{
  void work() => print("I always work");
  void sleep() {} // ??
}

abstract class Teacher{

void work();

void sleep();

}

class Human implements Teacher{

void work() => print("I do a lot of work");

void sleep() => print("I need 10 hours per night...");

}

class Robot implements Teacher{

void work() => print("I always work");

void sleep() {} // ??

}

The issue here is that robots do not require sleep, so we are unsure how to implement that method.

abstract class Teacher{
  void work();
}
abstract class Sleeper {
  void sleep();
}
class Human implements Teacher, Sleeper {
  void work() => print("I do a lot of work");
  void sleep() => print("I need 10 hours per night...");
}
class Robot implements Teacher{
  void work() => print("I'm always iiii work as teacher");
}

abstract class Teacher{

void work();

}

abstract class Sleeper {

void sleep();

}

class Human implements Teacher, Sleeper {

void work() => print("I do a lot of work");

void sleep() => print("I need 10 hours per night...");

}

class Robot implements Teacher{

void work() => print("I'm always iiii work as teacher");

}

Dependency Inversion Principle:

This principle suggests that high-level modules must not depend on low-level modules without an abstraction. Instead, both should depend on abstractions. In Flutter, this means relying on interfaces or abstract classes to define dependencies and decoupling the higher-level modules from the lower-level details.

Conclusion:

By incorporating the SOLID principles into your Flutter development, you can create clean, maintainable, and scalable code. These principles not only improve the quality of your application but also make it easier to adapt to changing requirements and reduce the overall development time.

Thanks for reading this article ❤

If I got something wrong 🙈, let me know in the comments. I would love to improve.

Reference Link:

Check out these interesting flutter topics:

nausheen Siddiqui

31 Jul, 2023
Updated by - nausheen Siddiqui
21 Dec, 2023
Updated by - nausheen Siddiqui

. . .

SOLID Principles In Flutter

Single Responsibility Principle:

Open/Closed Principle :

Liskov Substitution Principle :

Interface Segregation Principle:

Dependency Inversion Principle:

Conclusion:

Leave a Comment Cancel Reply

Message Sent!