eTechViral 01
SOLID IN FLUTTER
Swipe for more info
eTechViral 02
This is similar to what can happen when code is not
following the SOLID Principles
Each class module in your codebase should have a
specific purpose, and the methods and properties within
that class or module should be related to that purpose
just like each room in your house has its own set of tools
and applications, each class in your codebase should
have its own set of methods and properties that are
related to the class’s purpose
By following SOLID Principles, you can make your
codebase easier to understand, maintain and extend.
This can lead to more efficient and productive
development, and ultimately, a better experience for your
users.
eTechViral 03
Single Responsibility principle [SRP]
The SRP states that a class should have only one reason to change. In other
words, a class should have only one responsibility. This makes the class easier
to understand, maintain and test
Example: Suppose we have a class called user which is responsible for storing
user data. This class should not be responsible for sending an email or any
other unrelated tasks. Instead, we can create a separate class called
EmailSender to handle the Email sending task.
class user {
String name;
String email;
String password;
user({this.name, this.email, this.password});
//getter and setter methods
class emailSender{
void sendEmail(String recipient, String subject, String body) {
// send email using a third-party email service provider
}
eTechViral 04
Open/Close principle [OCP]
The OCP states that a class should be open for extension but closed for
modification. This means that we should be able to add new features to class
without modifying the existing code
Example: Suppose we have a class called PaymentGateway
which is responsible for processing payments. If we want to add support for a
new payment method like Google Pay, we should not modify the existing
PaymentGateway class. Instead, we can create a new class called
GooglepayGateway which extends the paymentgateway class.
abstract class PaymentGateway {
void processPayment();
class creditCardGateway implements PaymentsGateway {
void processPayment() {
// process payment using credit card
class GooglePayGateway implements PaymentGateway {
void processPayment() {
// process payment using Google Pay
}
eTechViral 05
Liskov Substitution Principle [LSP]
The LSP states that a subclass should be able to replace its parent class
without affecting the correctness of the program. This means that the subclass
should be able to implement all the methods of the parent class and behave in
the same way as parent class
Example: Suppose we have a class called Animal and its subclass called Dog. If
we have a method that accepts an Animal object, we should be able to pass a
Dog object to that method without causing any issues.
class Animal {
void main() {
void makesound() {
Animal animal = Animal();
print(‘Animal sound’);
Dog dog = Dog();
}
makeAnimalSound(animal);
}
// print ’Animnalsound’
class Dog extends Animal {
void makesound() {
makeAnimalSound(Dog); // Pprint ‘Bark’
print(‘bark’);
}
}
void makeAnimalSound(Animal animal) {
animal.sound();
eTechViral 06
Interface Segregation Principle [ISP]
The ISP states that a client should not be forced to implement methods it does
not use. In other words, we should not have large interfaces that contain
methods that are not relevant to all clients
Example: Suppose we have interface class printer and another interface called
scanner. The MultiFunctionPrinter class implements both interfaces, but the
LaserPrinter class only implements that printer interface. This way, a client can
use the LaserPrinter class without being forced to implement the
scanDocument method which is not relevant in this case.
abstract class printer {
void scanDocument() {
void printDocument();
// scan document
}
}
Abstract class Scanner {
}
void scanDocuments();
class LaserPrinter implements Printer {
}
void printDocument() {
class MultiFunctionPrinter implements // print document
printer, scanner {
void printDocument() {
}
// Prind document
}
07
eTechViral
Dependency Inversion Principle [DIP]
The DIP states that high-level modules should not depend on
low-level modules, Both should depend on abstraction. In
other words, classes should depend on interfaces or abstract
classes instead of concrete classes.
Example: Suppose we have class called PaymentProcessor
which needs to process payment gateway like PayPal or
Stripe, the Paymentprocesser should depend on an interface
called PaymentGateway that provides the necessary
methods for processing payments. This way can easily
switch between different payment gateway without
modifying the PaymentProcessor class.
Code on the next page
eTechViral 08
Code example of DIP
abstract class PaymentGateway {
void processPayment();
class PayPal implements PaymentGateway {
void prosessPayment() {
// process payment using PayPal
class Stripe implements PaymentGateway {
void processPayment() {
// Process payment using Stripe
class paymentprocessor {
PaymentGatway _getway;
PaymentProcessor(this._gateway);
void PaymentProcessor() {
_gateway.processPayment();
eTechViral 09
DO YOU FIND
THIS POST
USEFUL?
FOLLOW FOR MORE
