Open Closed Principle in Laravel (S.O.L.I.D)

Awang Trisakti
3 min readMar 13, 2023
Photo by Mike Petrucci on Unsplash

Open Closed Principle (OCP) is an essential aspect of the S.O.L.I.D principles of object-oriented programming. It suggests that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. In other words, developers should be able to add new features to an existing codebase without altering its current structure.

Consider a web application that allows users to payment. The application has several features, including set payment gateway and etc. As the application grows, it becomes more challenging to maintain, and developers may need to add new features without modifying the existing code.

For example if a user try to do a payment for a product in your web application and your apps has a various way of payment methods such as paypal, credit/debit card, bank transfer and etc. Lets look into the code below

// PaymentService.php
<?php

namespace App\Services;

class PaymentService
{
public function pay($type, $amount)
{
switch ($type) {
case 'paypal':
// Do paypal payment logic
break;
case 'bank':
// Do bank transfer payment logic
break;
}
}
}

In pay function of PaymentService.php, there is a switch for choosing payment method. Let say code in PaymentService.php is works well and no error found, in the other time it’s need to add a new payment method let say it’s a credit card so we need to modify our pay function in our service class, right? Well it’s look like a simple things to do, but if there is a lot and various of payment method then our service class might be very numerous and hard to maintain. It could be also lead us to human error that makes the code broken.

Here is example with OCP.

// PaymentInterface.php
<?php

namespace App\Interfaces;

interface PaymentInterface
{
public function pay($amount);
}

// PaypalPayment.php
<?php

namespace App\Payments;

use App\Interfaces\PaymentInterface;

class PaypalPayment implements PaymentInterface
{
public function pay($amount)
{
// Paypal payment logic here
}
}

// BankPayment.php
<?php

namespace App\Payments;

use App\Interfaces\PaymentInterface;

class BankPayment implements PaymentInterface
{
public function pay($amount)
{
// Bank payment logic here
}
}
// PaymentService.php
<?php

namespace App\Services;

class PaymentService
{
public function pay(PaymentInterface $payment, $amount)
{
$payment->pay($amount);
}
}

// in some classes that called PaymentService pay
<?php

namespace App\Classes;

class SomeClass
{
public function pay()
{
// Use payment needed
$payment = new Paypal();
(new PaymentService())->pay($payment, 1000);
}
}

In the example above we can set payment method as we need, and if there will be an addition of any other payment methods we are not need to modify or payment service class. We just need only to create a new payment class with implementation of PaymentInterface.

Conclusion
In my opinion, by applying the OCP in this way, we can maintain the application’s existing structure while adding new features. It makes the application more modular, flexible, and maintainable. We can also reduce the risk of introducing bugs and errors into the existing codebase.

That’s all that I can share in this post. I’m not an expert, so please feel free to leave comments for any suggestions or question, I would love to hear any feedbacks from you. Share this post if you found this post useful. See ya

--

--