Explore SOLID Principles In Flutter
I have been writing about design patterns for the past few articles, and I had promised to continue the series by concentrating on how they are used in Flutter development. I think it’s essential to comprehend the SOLID principles. There is always space for a deeper comprehension, even if we believe we already comprehend these concepts.
In this blog, we will Explore SOLID Principles In Flutter. We will see how to work on a deep dive guide for your Flutter applications.
If you’re looking for the best Flutter app development company for your mobile application then feel free to contact us at — support@flutterdevs.com.
Table Of Contents:
What are the SOLID Principles?
Introduction:
A collection of five design guidelines known as the SOLID principles aids programmers in producing scalable and maintainable software. When creating your Flutter apps, you can use them, as they are extensively relevant in object-oriented programming.
What are the SOLID Principles?
Robert C. Martin, sometimes known as Uncle Bob, presented the SOLID principles in his paper Design Principles and Design Patterns. The goal of these guidelines was to improve the readability, adaptability, and maintainability of software designs. SOLID is an acronym that stands for:
- S: Single Responsibility Principle (SRP)
- O: Open-Closed Principle (OCP)
- L: Liskov Substitution Principle (LSP)
- I: Interface Segregation Principle (ISP)
- D: Dependency Inversion Principle (DIP)
By reducing dependencies between software components, these concepts offer a method for decoupling software and increasing its modularity, flexibility, and adaptability to changes. Although they can be applied to other paradigms, object-oriented programming is where they are most frequently used.
=> Single Responsibility Principle (SRP):
The Single Responsibility Principle (SRP) states that there should only be one justification for a class to change. Let’s look at an example to better grasp this idea.
Issue:-
class User {
String name;
String email;
User(this.name, this.email);
void changeEmail(String newEmail) {
if (validateEmail(newEmail)) {
this.email = newEmail;
} else {
print('Invalid email');
}
}
bool validateEmail(String email) {
return email.contains('@');
}
}The User class in the code above violates the Single Responsibility Principle (SRP) since it has two duties: email validation and user data management.
Solution:-
class User {
String name;
String email;
User(this.name, this.email);
void changeEmail(String newEmail) {
if (EmailValidator.validate(newEmail)) {
this.email = newEmail;
} else {
print('Invalid email');
}
}
}
class EmailValidator {
static bool validate(String email) {
return email.contains('@');
}
}The User class is now only in charge of handling user data, while the EmailValidator class is solely in charge of email validation. The Single Responsibility Principle (SRP) is upheld here.
=> Open-Closed Principle (OCP):
Software entities (classes, modules, functions, etc.) should be open for expansion but closed for modification under the Open-Closed Principle (OCP). Let’s look at an example to better grasp this idea
Issue:-
class Languages {
void languages(String language) {
switch (language) {
case 'English':
print('Hello!');
break;
case 'Spanish':
print('Hola!');
break;
default:
print('Language not supported');
}
}
}The Open-Closed Principle (OCP) will be broken if I add a new language because I will need to change the languages() procedure.
Solution:-
By developing distinct classes for every language that implement a common Languages interface, we may resolve this issue.
abstract class Languages {
void greet();
}
class EnglishLanuages implements Languages {
@override
void lanuages() {
print('Hello!');
}
}
class SpanishLanguages implements Languages {
@override
void languages() {
print('Hola!');
}
}
class FrenchLanguages implements Languages {
@override
void languages() {
print('Bonjour!');
}
}
class HindiLanguages implements Languages {
@override
void languages() {
print("Namaste!");
}
}The Languages interface is now closed for modification (we are not required to change the Languages interface or any of the existing classes), but it is open for extension (we can add other languages by establishing new classes). The Open-Closed Principle is followed here.
=> Liskov Substitution Principle (LSP):
The Liskov Substitution Principle (LSP) states that each instance of a derived (child) class ought to be interchangeable with an instance of its base (parent) class without compromising the program’s validity. Let’s look at an example to better grasp this idea.
Issue:-
class AquaticAnimals {
void fly() {
print('Swim...');
}
}
class Bird extends AquaticAnimals {
@override
void fly() {
throw Exception('Birds can\'t swim!');
}
}Although the code above indicates that the Bird class is a subclass of AquaticAnimals, it lacks some of the capabilities of AquaticAnimals, such as the ability to swim. We may run into problems that violate the Liskov Substitution Principle (LSP) when we try to substitute a bird for an aquatic animal.
Solution:-
abstract class AquaticAnimals {
void eat();
}
abstract class SwimAquaticAnimals extends AquaticAnimals {
void swim();
}
abstract class NonSwimAquaticAnimals extends AquaticAnimals {}
class Whale implements SwimAquaticAnimals {
@override
void eat() {
print("Eating...");
}
@override
void fly() {
print('Swim...');
}
}
class Bird implements NonSwimAquaticAnimals {
@override
void eat() {
print("Eating...");
}
}Now, an aquatic animals can always be replaced by a SwimAquaticAnimals, and an aquatic animal may always be replaced by a NonSwimAquaticAnimals. The Liskov Substitution Principle (LSP) is upheld here.
=> Interface Segregation Principle (ISP):
The Interface Segregation Principle (ISP) states that it is preferable to design smaller, more targeted interfaces for particular use cases rather than a single, comprehensive interface that encompasses all potential approaches. Let’s look at an example to better grasp this idea.
Issue:-
abstract class Bird {
void eat();
void sleep();
void fly();
}The Bird interface in the code above has several duties. A bird must use one of these techniques even if it is not necessary (for example, a dog cannot fly). The Interface Segregation Principle (ISP) is broken by this.
Solution:-
By developing distinct interfaces for every duty, we can resolve this.
abstract class Eater {
void eat();
}
abstract class Sleeper {
void sleep();
}
abstract class Flyer {
void fly();
}
class Bird implements Eater, Sleeper, Flyer {
@override
void eat() {
print("Eating..");
}
@override
void sleep() {
print("Sleeping..");
}
@override
void fly() {
print("Flying..");
}
}
class Dog implements Eater, Sleeper {
@override
void eat() {
print("Eating..");
}
@override
void sleep() {
print("Sleeping..");
}
}A bird can now implement only the interfaces it needs, and each interface has a single responsibility. This complies with the principle of interface segregation.
=> Dependency Inversion Principle (DIP):
The Dependency Inversion Principle (DIP) states that both high-level and low-level modules should rely on abstractions rather than on one another. Let’s look at an example to better grasp this idea.
Issue:-
class WeatherService {
String getWeather() {
return "Sunny";
}
}
class WeatherReporter {
WeatherService _weatherService;
WeatherReporter(this._weatherService);
void reportWeather() {
String weather = _weatherService.getWeather();
print('The weather is $weather');
}
}The WeatherReporter class in the code above depends directly on the WeatherService class. The WeatherReporter class must be changed if we wish to alter how we obtain the weather (for instance, by utilising a different weather provider). The Dependency Inversion Principle (DIP) is broken by this.
Solution:-
By developing a WeatherProvider interface and making WeatherReporter rely on it rather than the actual WeatherService, we can resolve this issue.
abstract class WeatherProvider {
String getWeather();
}
class WeatherService implements WeatherProvider {
@override
String getWeather() {
return "Sunny";
}
}
class WeatherReporter {
WeatherProvider _weatherProvider;
WeatherReporter(this._weatherProvider);
void reportWeather() {
String weather = _weatherProvider.getWeather();
print('The weather is $weather');
}
}Instead of relying on the actual WeatherService, the WeatherReporter class now depends on the abstraction (WeatherProvider). Simply create a new class that implements WeatherProvider if we wish to modify how we obtain the weather. The WeatherReporter class doesn’t need to be changed. The Dependency Inversion Principle (DIP) is followed here.
Conclusion:
In the article, I have explained the basic structure of SOLID Principles in Flutter; you can modify this code according to your choice. This was a small introduction to SOLID Principles in Flutter on User Interaction from my side, and it’s working using Flutter.
I hope this blog will provide you with sufficient information on trying up Explore SOLID Principles in your Flutter projects. We will show you what an Introduction is?. A collection of rules known as the SOLID principles can assist you in writing code that is reliable and easy to maintain. It’s crucial to use them sensibly and avoid making things too complicated. You must comprehend these principles’ goals and use them correctly to improve the calibre of your software design if you want to get the most out of them.. So please try it.
❤ ❤ Thanks for reading this article ❤❤
If I got something wrong? Let me know in the comments. I would love to improve.
Clap 👏 If this article helps you.
Feel free to connect with us:
And read more articles from FlutterDevs.com.
FlutterDevs team of Flutter developers to build high-quality and functionally-rich apps. Hire flutter developer for your cross-platform Flutter mobile app project on an hourly or full-time basis as per your requirement! For any flutter-related queries, you can connect with us on Facebook, GitHub, Twitter, and LinkedIn.
We welcome feedback and hope that you share what you’re working on using #FlutterDevs. We truly enjoy seeing how you use Flutter to build beautiful, interactive web experiences.
