Scribd
Upload
38 views5 pages

Five SOLID Principles

Uploaded by

enaoujneor
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
38 views5 pages

Five SOLID Principles

Uploaded by

enaoujneor
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/ 5

Five SOLID principles

The SOLID principles are a set of five design principles in object-oriented programming that
help developers build systems that are easy to maintain, scalable, and robust. Here's an
overview of the SOLID principles:

1. Single Responsibility Principle (SRP)


Definition: A class should have only one reason to change, meaning it should have only
one job or responsibility.

Explanation: Each class should focus on a single functionality or responsibility. If a


class has more than one responsibility, changes in one area could affect the other,
leading to bugs and complexity.
Example: If you have a User class that handles user data and also sends emails,
you're violating SRP. To adhere to SRP, you should have separate classes: one for user
management and one for handling emails.

In Code:

class User {
// Responsibility: User data
}

class EmailService {
// Responsibility: Sending emails
}

2. Open/Closed Principle (OCP)


Definition: Software entities (classes, modules, functions, etc.) should be open for
extension but closed for modification.

Explanation: You should be able to extend the behavior of a class without modifying its
source code. This is often achieved through abstractions (e.g., interfaces, abstract
classes) and inheritance.
Example: If you have a payment processing class and need to add a new payment
method (e.g., PayPal), you shouldn't modify the original class but rather extend it by
adding new functionality.

In Code:
interface PaymentMethod {
void processPayment(double amount);
}

class CreditCardPayment implements PaymentMethod {


public void processPayment(double amount) {
// Process credit card payment
}
}

class PayPalPayment implements PaymentMethod {


public void processPayment(double amount) {
// Process PayPal payment
}
}

3. Liskov Substitution Principle (LSP)


Definition: Objects of a superclass should be replaceable with objects of its subclasses
without affecting the correctness of the program.

Explanation: Subclasses should behave like their base class. If you replace a base
class object with a subclass object, the program should still work as expected. This
means that subclasses should not violate the contract established by the base class.
Example: If a base class Bird has a method fly() , a subclass Penguin (which
can't fly) should not override this method with behavior that contradicts the base class.

In Code:

class Bird {
public void fly() {
System.out.println("Flying...");
}
}

class Sparrow extends Bird {


// Sparrow can fly, so no issues here.
}

class Penguin extends Bird {


@Override
public void fly() {
throw new UnsupportedOperationException("Penguins can't fly!");
}
}

To fix the LSP violation, you could separate birds into flying and non-flying birds:

class Bird {
// No fly method in the base class
}

class FlyingBird extends Bird {


public void fly() {
System.out.println("Flying...");
}
}

class Penguin extends Bird {


// Penguins don't fly, so no fly method
}

4. Interface Segregation Principle (ISP)


Definition: Clients should not be forced to depend on interfaces they do not use.

Explanation: A class should not implement methods it does not need. If a class is
forced to implement methods that it doesn't require, it's better to break down large
interfaces into smaller, more specific ones.
Example: If you have an interface Worker with methods work() and eat() , a class
representing a robot may not need eat() . Instead, you should have separate
interfaces like Workable and Eatable .

In Code:

interface Workable {
void work();
}

interface Eatable {
void eat();
}

class HumanWorker implements Workable, Eatable {


public void work() {
System.out.println("Working...");
}
public void eat() {
System.out.println("Eating...");
}
}

class RobotWorker implements Workable {


public void work() {
System.out.println("Working...");
}
}

5. Dependency Inversion Principle (DIP)


Definition: High-level modules should not depend on low-level modules. Both should
depend on abstractions. Also, abstractions should not depend on details, but the details
should depend on abstractions.

Explanation: This principle encourages the decoupling of high-level business logic


from low-level implementation details. High-level classes should depend on interfaces
or abstract classes rather than concrete implementations, and low-level classes should
implement those interfaces.
Example: If a PaymentProcessor class directly depends on a concrete
CreditCardPayment class, it’s hard to switch to another payment method. Instead,
make the PaymentProcessor depend on an abstract PaymentMethod interface, and
concrete payment methods like CreditCardPayment or PayPalPayment can
implement that interface.

In Code:

interface PaymentMethod {
void processPayment(double amount);
}

class PaymentProcessor {
private PaymentMethod paymentMethod;

public PaymentProcessor(PaymentMethod paymentMethod) {


this.paymentMethod = paymentMethod; // Depends on abstraction
}

public void process(double amount) {


paymentMethod.processPayment(amount);
}
}
class CreditCardPayment implements PaymentMethod {
public void processPayment(double amount) {
System.out.println("Processing credit card payment...");
}
}

class PayPalPayment implements PaymentMethod {


public void processPayment(double amount) {
System.out.println("Processing PayPal payment...");
}
}

Summary of SOLID Principles:


Single Responsibility Principle: A class should only have one responsibility.
Open/Closed Principle: Classes should be open for extension but closed for
modification.
Liskov Substitution Principle: Subtypes should be substitutable for their base types.
Interface Segregation Principle: No class should be forced to depend on methods it
does not use.
Dependency Inversion Principle: High-level modules should depend on abstractions,
not concrete implementations.

Following SOLID principles leads to cleaner, more maintainable, and scalable code.

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