DEV Community: Muhammad Raza Bangi

Interface Segregation Principle (ISP) By Using PHP : SOLID Principle

Muhammad Raza Bangi — Sun, 18 Feb 2024 20:57:57 +0000

Introduction:

Hey there, fellow coders!

Welcome to my article where we’re going to dive into the world of programming principles. Today’s topic? The Interface Segregation Principle (ISP). Don’t let the fancy name scare you off — I promise to make it as fun and easy to understand as playing your favorite video game!

What is the Interface Segregation Principle?

Imagine you’re in a library 📚 browsing through books. Each book covers a different topic, like science, history, or fiction. Now, what if you’re only interested in science books? You wouldn’t want to be forced to check out books from every section, right?

Well, that’s where the Interface Segregation Principle (ISP) comes into play in programming. It’s like organizing the library so that you can find exactly the books you’re interested in.

In programming, ISP says we shouldn’t make a class handle tasks it doesn’t need to. Just like in the library, we wouldn’t force everyone to check out books from every section. Instead, we’d break down big tasks into smaller ones, so each class only deals with what it’s meant for. It’s like creating a custom library card — you only borrow the books you want to read, and nothing else!

Interface segregation principle states:

A client should never be forced to implement an interface that it doesn’t use, or clients shouldn’t be forced to depend on methods they do not use.

ISP in Action: A Practical Example

Now, let’s dive into a real-life example to see how ISP works in action. We’ll look at a piece of code that’s not following the ISP and compare it to a version that does. Trust me, you’ll see a big difference!

interface EmployeeInterface {
    public function takeOrder();
    public function washDishes();
    public function cookFood();
}

class Waiter implements EmployeeInterface {
    public function takeOrder() {
      echo "take order.";  
    }

    public function washDish() {
      echo "not my job.";  
    }

    public function cookFood() {
      echo "not my job.";  
    }
}

$foo = new Waiter();
$foo->takeOrder();

In the provided code snippet, we have an EmployeeInterface interface that defines three methods: takeOrder(), washDish(), and cookFood(). However, the Waiter class, which implements the Employee interface, is forced to implement all three methods, even though it's not responsible for washing dishes or cooking food. This violates the Interface Segregation Principle (ISP), which suggests that classes should not be forced to implement interfaces containing methods they don't need. By adhering to ISP, we can avoid bloated interfaces and ensure that each class only implements the methods relevant to its specific responsibilities. This promotes better code organization, flexibility, and maintainability in our software systems.

Now Interface Segregation Principle (ISP) comes in action:

//interfaces
interface WaiterInterface {
    public function takeOrder();
}

interface ChefInterface {
    public function cookFood();
}

interface DishWasherInterface {
    public function washDish();
}

//classes
class Waiter implements WaiterInterface {
    public function takeOrder() {
        echo "take order.";
    }
}

class Chef implements ChefInterface {
    public function cookFood() {
        echo "cook food.";
    }
}

class DishWasher implements DishWasherInterface {
    public function washDish() {
        echo "wash dish.";
    }
}

In this updated code snippet, we’ve applied the Interface Segregation Principle (ISP) by breaking down the large Employee interface into smaller, more specialized interfaces: WaiterInterface, ChefInterface, and DishWasherInterface. Each interface contains only the methods relevant to the specific responsibilities of the corresponding class.

The Waiter class implements the WaiterInterface and provides the takeOrder() method, which is its primary responsibility. Similarly, the Chef class implements the ChefInterface with the cookFood() method, and the DishWasher class implements the DishWasherInterface with the washDish() method.

By using ISP, we ensure that each class is only concerned with the methods related to its role, promoting better code organization and maintainability. This approach allows us to easily add or modify functionality without impacting unrelated classes, making our code more flexible and adaptable to change. Overall, adhering to ISP leads to cleaner, more focused code and a more robust software design.

Conclusion:

In conclusion, the Interface Segregation Principle (ISP) provides a valuable guideline for designing interfaces in object-oriented programming. By breaking down large interfaces into smaller, specialized ones, we ensure that classes are only responsible for implementing the methods relevant to their specific roles.

In the example provided, we saw how applying ISP resulted in cleaner, more focused code. Each class, whether it be the Waiter, Chef, or DishWasher, only implemented the methods necessary for its particular responsibilities. This not only improves code readability and maintainability but also allows for easier extension and modification in the future.

By following ISP, we can create software systems that are more flexible, scalable, and resilient to change. It encourages modular design and promotes better separation of concerns, ultimately leading to more robust and efficient codebases.

Incorporating ISP into our coding practices helps us build software that is easier to understand, debug, and maintain, ultimately contributing to the overall success of our projects. So, let’s keep the principles of ISP in mind as we continue to develop software solutions, striving for code that is both elegant and effective.

Thank you for reading. :)

Single Responsibility Principle (SRP) By Using PHP : SOLID Principle

Muhammad Raza Bangi — Sat, 17 Feb 2024 18:23:36 +0000

Introduction:

Welcome to my article where we’ll explore a super important concept in programming called the Single Responsibility Principle (SRP). Single Responsibility Principle (SRP)! It’s a key concept in programming that helps keep our code neat and easy to understand. So, let’s dive in and make sure you’ve got it all figured out!

Robert C. Martin describes it:

A class should have one and only one reason to change, meaning that a class should have only one job.

What is the Single Responsibility Principle?

So, what’s this SRP thing all about? Well, think of it like this: imagine you have a bunch of toys in your room. Each toy should have its own job, right? Like, a ball is for bouncing, and a teddy bear is for cuddling. In programming, the SRP says that each part of your code should have just one job to do. It’s like keeping your toys organized so you can find them easily when you need them!

SRP in Action: A Practical Example

Now, let’s dive into a real-life example to see how SRP works in action. We’ll look at a piece of code that’s not following the SRP and compare it to a version that does. Trust me, you’ll see a big difference!

class Product {
    private string $name;
    private string $color;
    private int $price;

    public function __construct(
        $name,
        $color,
        $price
    ) {
        $this->name = $name;
        $this->color = $color;
        $this->price = $price;
    }

    public function getPrice() {
        return $this->price;
    }

    public function getProductDetails(): void {
        printf(
            "Product name: %s,\nColor: %s,\nPrice: %d", 
            $this->name, 
            $this->color,
            $this->price 
        );
    }
}

class Invoice {
    private Product $product;
    private int $quantity;

    public function __construct(Product $product, int $quantity) {
        $this->product = $product;
        $this->quantity = $quantity;
    }

    public function calculateTotal(): int {
        return $this->product->getPrice() * $this->quantity;
    }

    public function invoicePrint(): void {
        echo "Invoice print.";
    }

    public function saveToDB(): void {
        echo "Invoice saved in DB.";
    }
}

Here we have a simple PHP code snippet with two classes: Product and Invoice.

The Product class holds details about a product like its name, color, and price. Pretty straightforward, right? It's like having a label on a box that tells you exactly what's inside.

Now, let’s talk about the Invoice class. Its job is to handle invoices, but here's the catch: it's doing more than it should! According to the Single Responsibility Principle (SRP) by Robert C. Martin, each class should have just one reason to change. But in our case, the Invoice class is handling three things: calculating the total, printing the invoice, and saving invoice data to the database.

It’s like having one person trying to do three different jobs at once — it’s bound to get messy! To follow SRP, we’d want to split up these responsibilities into separate classes. That way, each class can focus on doing one thing really well, making our code easier to understand and maintain.

By refactoring our code to follow SRP, we’ll end up with classes that are simpler, more flexible, and easier to work with. And that’s a win-win for everyone involved! 🚀💻

Now Single Responsibility Principle comes in action:

class Product {
    private string $name;
    private string $color;
    private int $price;

    public function __construct(
        $name,
        $color,
        $price
    ) {
        $this->name = $name;
        $this->color = $color;
        $this->price = $price;
    }

    public function getPrice() {
        return $this->price;
    }

    public function getProductDetails(): void {
        printf(
            "Product name: %s,\nColor: %s,\nPrice: %d", 
            $this->name, 
            $this->color,
            $this->price 
        );
    }
}

class Invoice {
    private Product $product;
    private int $quantity;

    public function __construct(Product $product, int $quantity) {
        $this->product = $product;
        $this->quantity = $quantity;
    }

    public function calculateTotal(): int {
        return $this->product->getPrice() * $this->quantity;
    }
}

class InvoicePrinter {
    private Invoice $invoice;

    public function __construct(Invoice $invoice) {
        $this->invoice = $invoice;
    }

    public function print(): void {
        echo "Invoice print";
    }
}

class InvoiceDB {
    private Invoice $invoice;

    public function __construct(Invoice $invoice) {
        $this->invoice = $invoice;
    }

    public function save(): void {
        echo "Invoice saved in DB.";
    }
}

In this updated code snippet, we’ve successfully applied the Single Responsibility Principle (SRP), keeping our classes focused and organized.

The Product class is responsible for holding product details such as name, color, and price. It's like a neat little package that tells us everything we need to know about a product.

Then, we have the Invoice class, which now has a single responsibility: calculating the total amount based on the product price and quantity. It's like a dedicated accountant crunching the numbers to give us the final bill.

But wait, there’s more! We’ve introduced two new classes: InvoicePrinter and InvoiceDB. These classes each handle a specific task related to invoices. The InvoicePrinter class is responsible for printing invoices, while the InvoiceDB class takes care of saving invoice data to the database.

By breaking down responsibilities into separate classes, we’ve made our code cleaner, easier to understand, and more flexible. Now, each class can focus on its own job without getting tangled up in unrelated tasks. It’s like having a well-oiled machine where each part does its job smoothly and efficiently.

With our code structured this way, future changes and updates will be a breeze. And that’s what following SRP is all about — making our codebase more robust and maintainable for the long haul. 🌟💻

Conclusion:

In conclusion, by following the Single Responsibility Principle (SRP), we’ve made our code easier to work with and understand, kind of like organizing your toys into different boxes so you can find them easily when you need them!

Breaking down responsibilities into smaller, focused tasks has made our codebase more flexible and adaptable, just like having a toolbox with specific tools for different jobs.

Whether you’re a beginner just starting out or an advanced developer, SRP helps keep our code neat and tidy, making it easier for everyone to collaborate and contribute.

So, remember, when in doubt, keep it simple and focused — your future self (and your teammates) will thank you for it! Happy coding! 🚀💻

Thank you for your precious time to read :)

Open/Closed Principle (OCP) By Using PHP : SOLID Principle

Muhammad Raza Bangi — Wed, 14 Feb 2024 23:29:22 +0000

Introduction:

In the world of software development, adhering to SOLID principles is essential for building maintainable and scalable applications. Today, we will dive into the Open-Closed Principle (OCP) and explore how it can be applied in PHP. Let’s unlock the potential of OCP!

What is the Open-Closed Principle?

The Open-Closed Principle, one of the SOLID principles, states that software entities (classes, modules, functions) should be open for extension but closed for modification. In simpler terms, we should be able to extend the behavior of a class without modifying its existing code. This promotes code reusability and makes our applications more flexible and easier to maintain.

OCP in Action: A Practical Example

Consider a scenario where we have a “CreditCardPayment” class responsible for processing payments in our e-commerce application. Initially, it only supports credit card payments.

class CreditCardPayment {
    private string $title;
    private string $accountNumber;
    private int $balance = 1000;
    private int $serviceCharges = 50;

    public function __construct(string $title, string $accountNumber) {
        $this->title = $title;
        $this->accountNumber = $accountNumber;
    }

    public function pay(int $number) {
        $last4Digits = substr($this->accountNumber, -4);
        $this->balance = ($this->balance - $number) - $this->serviceCharges;

        printf(
          "Hello %s,\nPay successfully against xxxx-%s, Your remaining balance is %d", 
          $this->title, 
          $last4Digits, 
          $this->balance
        );
    }
}

$creditCard = new CreditCardPayment("Muhammad Raza Bangi", "123456789");
$creditCard->pay(100);

// output:
Hello Muhammad Raza Bangi,
Pay successfully against xxxx-6789, Your remaining balance is 850

So far, our system has been processing payments only via credit card. Now, our client has an additional request: they want to integrate PayPal as another payment method, and PayPal has its own set of service charges. No worries, we can handle this. Instead of limiting our class to credit card payments, let’s make it more versatile. We’ll change the class name from CreditCardPayment to simply Payment. Because our system processing two payment methods so class name should be generic.

class Payment {
    private string $title;
    private string $accountNumber;
    private string $paymentType;

    private int $balance = 1000;
    private int $creditCardServiceCharges = 50;
    private int $paypalServiceCharges = 100;

    public function __construct(
          string $title, 
          string $accountNumber, 
          string $paymentType
    ) {
        $this->title = $title;
        $this->accountNumber = $accountNumber;
        $this->paymentType = $paymentType;
    }

    public function pay(int $number) {
        $last4Digits = substr($this->accountNumber, -4);

        if ($this->paymentType === 'credit') {
            $this->balance = ($this->balance - $number) - $this->creditCardServiceCharges;
        } else if ($this->paymentType === 'paypal') {
            $this->balance = ($this->balance - $number) - $this->paypalServiceCharges;
        } else {
            echo "Invalid payment type, expect paypal or credit";
            exit;
        }

        printf(
            "Hello %s,\nPay successfully against xxxx-%s, Your remaining balance is %d\n", 
            $this->title, 
            $last4Digits, 
            $this->balance
        );
    }
}

$paypal = new Payment("Muhammad Raza Bangi", "123456789", "paypal");
$paypal->pay(100);

$creditCard = new Payment("Muhammad Raza Bangi", "987654321", "credit");
$creditCard->pay(100);

//output
(paypal instance output)
Hello Muhammad Raza Bangi,
Pay successfully against xxxx-6789, Your remaining balance is 800

(creditcard instance output)
Hello Muhammad Raza Bangi,
Pay successfully against xxxx-4321, Your remaining balance is 850

Ah, just when I was enjoying my coffee, the client throws in another curveball: they want to integrate Stripe as yet another payment method. It’s like a never-ending adventure! But hey, no need to stress out. Instead of tearing apart our existing code again, let’s keep it calm and cool.

Now Open/Closed Principle comes in action:

Now, let’s explore how the Open/Closed Principle can be put into practice. Here’s how we can achieve that by utilizing abstract classes or interfaces.

abstract class Payment {
    protected string $title;
    protected string $accountNumber;
    protected int $balance = 1000;
    protected int $last4Digits;

    public function __construct(
          string $title, 
          string $accountNumber
    ) {
        $this->title = $title;
        $this->accountNumber = $accountNumber;
        $this->last4Digits = substr($this->accountNumber, -4);
    }

    public abstract function pay(int $number);
}

class CreditCard extends Payment {
    private int $charges = 50;

    public function pay(int $number) {
        $this->balance = ($this->balance - $number) - $this->charges;

        printf(
            "Hello %s,\nPay successfully against xxxx-%s, Your remaining balance is %d\n", 
            $this->title, 
            $last4Digits, 
            $this->balance
        );
    }
}

class Paypal extends Payment {
    private $charges = 100;

    public function pay(int $number) {
        $this->balance = ($this->balance - $number) - $this->charges;

        printf(
            "Hello %s,\nPay successfully against xxxx-%s, Your remaining balance is %d\n", 
            $this->title, 
            $last4Digits, 
            $this->balance
        );
    }
}

$creditCard = new CreditCard("Muhammad Raza Bangi", "123456789");
$creditCard->pay(200);

$paypal = new Paypal("Muhammad Raza Bangi", "987654321");
$paypal->pay(200);

//output
(creditcard instance output)
Hello Muhammad Raza Bangi,
Pay successfully against xxxx-6789, Your remaining balance is 750

(paypal instance output)
Hello Muhammad Raza Bangi,
Pay successfully against xxxx-4321, Your remaining balance is 700

Instead of directly modifying existing code, we’ll establish a blueprint for different payment methods using an interface or an abstract class. This blueprint will define the common behavior expected from all payment methods. Here are the example where you can see my code is open for extension but close for modification. Now i can add multiple payment methods without update/change/modify my existing Payment class. By following this approach, we ensure that our code remains closed for modification. Adding a new payment method becomes a matter of creating a new class that conforms to the established blueprint, rather than altering existing code. This way, we maintain the integrity and extensibility of our codebase while adhering to the Open/Closed Principle.

Lets Take an another example by using interface:

interface Payment {
    public function pay(int $number);
    public function accountDetails();
}

class CreditCard implements Payment {
    private string $title;
    private string $accountNumber;
    private int $balance = 1000;
    private int $charges = 50;

    public function __construct(string $title, string $accountNumber) {
        $this->title = $title;
        $this->accountNumber = $accountNumber;
    }

    public function pay(int $number) {
        $this->balance = ($this->balance - $number) - $this->charges;

        return $this->balance;
    }

    public function accountDetails() {
        $last4Digits = substr($this->accountNumber, -4);

        printf(
            "Hello %s,\nYour remaining balance is %d against xxxx-%s\n", 
            $this->title, 
            $this->balance,
            $last4Digits, 
        );
    }
}


class Paypal implements Payment {
    private string $title;
    private string $accountNumber;
    private int $balance = 1000;
    private int $charges = 100;

    public function __construct(string $title, string $accountNumber) {
        $this->title = $title;
        $this->accountNumber = $accountNumber;
    }

    public function pay(int $number) {
        $this->balance = ($this->balance - $number) - $this->charges;

        return $this->balance;
    }

    public function accountDetails() {
        $last4Digits = substr($this->accountNumber, -4);

        printf(
            "Hello %s,\nYour remaining balance is %d against xxxx-%s\n", 
            $this->title, 
            $this->balance,
            $last4Digits, 
        );
    }
}

function showDetails(Payment $payment) {
    $payment->accountDetails();
}

$creditCard = new CreditCard("Muhammad Raza Bangi", "123456789");
$creditCard->pay(100);
showDetails($creditCard);

$paypal = new Paypal("Muhammad Raza Bangi", "987654321");
$paypal->pay(200);
showDetails($paypal);

//output
(creditcard instance output)
Hello Muhammad Raza Bangi,
Your remaining balance is 850 against xxxx-6789

(paypal instance output)
Hello Muhammad Raza Bangi,
Your remaining balance is 700 against xxxx-4321

Conclusion:

The Open-Closed Principle encourages us to write flexible and extensible code, making our applications more robust and easier to maintain. By adhering to OCP in PHP, specifically in Laravel, we can build software that adapts to change with grace. Embrace the OCP mindset, and your code will be on a path of continuous improvement! Happy coding! 🚀👩‍💻

Thank you for your precious time to read :)

Muhammad Raza Bangi — Tue, 28 Jun 2022 21:06:45 +0000