Scribd
Upload
71 views

Solid in Flutter

The document discusses the SOLID principles of object-oriented design, which are Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. Each principle is explained with a coding example to illustrate how to apply the principle to make code easier to understand, maintain, and extend. Following the SOLID principles can lead to more efficient development and a better user experience.

Uploaded by

شہزاد رحیم
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
71 views

Solid in Flutter

The document discusses the SOLID principles of object-oriented design, which are Single Responsibility Principle, Open/Closed Principle, Liskov Substitution Principle, Interface Segregation Principle, and Dependency Inversion Principle. Each principle is explained with a coding example to illustrate how to apply the principle to make code easier to understand, maintain, and extend. Following the SOLID principles can lead to more efficient development and a better user experience.

Uploaded by

شہزاد رحیم
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 9

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

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy