The Open-Closed Principle (OCP) is one of the five SOLID principles of object-oriented design. which states that software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. This means that you should be able to extend the behavior of a software entity without changing its source code.

Example: Payment Gateway Integration

Suppose you are building an e-commerce website that allows customers to make payments using different payment gateways such as PayPal, Stripe, and Authorize. Net. To implement this feature, you might create a PaymentGateway class with different methods for each payment gateway:

class PaymentGateway {
    public function payWithPayPal() {
        // logic for PayPal payment
    }

    public function payWithStripe() {
        // logic for Stripe payment
    }

    public function payWithAuthorizeNet() {
        // logic for Authorize.Net payment
    }
}

However, this violates the OCP principle because if you want to add support for a new payment gateway, you will have to modify the PaymentGateway class. To apply the OCP principle, you can create an interface called PaymentGatewayInterface:

interface PaymentGatewayInterface {
    public function pay();
}

Then, you can create separate classes for each payment gateway that implement the PaymentGatewayInterface:

class PayPalGateway implements PaymentGatewayInterface {
    public function pay() {
        // logic for PayPal payment
    }
}

class StripeGateway implements PaymentGatewayInterface {
    public function pay() {
        // logic for Stripe payment
    }
}

class AuthorizeNetGateway implements PaymentGatewayInterface {
    public function pay() {
        // logic for Authorize.Net payment
    }
}

In this way, you have extended the behavior of the PaymentGateway class without modifying its source code. Now, you can add support for a new payment gateway by creating a new class that implements the PaymentGatewayInterface.

Now let's expand this example and come up with a small app

First, let's create an interface for the payment gateway:

// app/PaymentGateway.php

namespace App;

interface PaymentGateway
{
    public function processPayment($amount);
}

Next, we can create separate classes for each payment gateway that implements the PaymentGateway interface:

// app/StripePaymentGateway.php

namespace App;

class StripePaymentGateway implements PaymentGateway
{
    public function processPayment($amount)
    {
        // Logic for processing payment with Stripe
    }
}

// app/PayPalPaymentGateway.php

namespace App;

class PayPalPaymentGateway implements PaymentGateway
{
    public function processPayment($amount)
    {
        // Logic for processing payment with PayPal
    }
}

// app/AuthorizeNetPaymentGateway.php

namespace App;

class AuthorizeNetPaymentGateway implements PaymentGateway
{
    public function processPayment($amount)
    {
        // Logic for processing payment with Authorize.Net
    }
}

We can then create a PaymentProcessor class that takes an instance of the PaymentGateway interface and uses it to process the payment:

// app/PaymentProcessor.php

namespace App;

class PaymentProcessor
{
    private $gateway;

    public function __construct(PaymentGateway $gateway)
    {
        $this->gateway = $gateway;
    }

    public function processPayment($amount)
    {
        $this->gateway->processPayment($amount);
    }
}

Finally, we can use the PaymentProcessor class in a controller to process payments:

// app/Http/Controllers/PaymentController.php

namespace App\Http\Controllers;

use App\PaymentProcessor;
use App\StripePaymentGateway;
use App\PayPalPaymentGateway;
use App\AuthorizeNetPaymentGateway;
use Illuminate\Http\Request;

class PaymentController extends Controller
{
    public function processPayment(Request $request)
    {
        $amount = 100; // The amount to be charged

        // Determine which payment gateway to use based on the environment variable
        $gatewayName = $request->input('gateway', env('PAYMENT_GATEWAY', 'stripe'));

        switch ($gatewayName) {
            case 'paypal':
                $gateway = new PayPalPaymentGateway();
                break;
            case 'authorizenet':
                $gateway = new AuthorizeNetPaymentGateway();
                break;
            default:
                $gateway = new StripePaymentGateway();
                break;
        }

        $processor = new PaymentProcessor($gateway);
        $processor->processPayment($amount);
    }
}

In this way, we have extended the behavior of the PaymentGateway class without modifying its source code, by creating separate classes for each payment gateway that implement the PaymentGateway interface. We have also used the PaymentProcessor class to process payments using any payment gateway that implements the PaymentGateway interface.

We can move the payment gateway selection logic to FactoryClass That way our controller will be clean

we can refactor the PaymentController to use a factory class for creating the payment gateway instances. Here's an example:

// app/Http/Controllers/PaymentController.php

namespace App\Http\Controllers;

use App\PaymentProcessor;
use App\PaymentGatewayFactory;
use Illuminate\Http\Request;

class PaymentController extends Controller
{
    public function processPayment(Request $request)
    {
        $amount = 100; // The amount to be charged

        $factory = new PaymentGatewayFactory();
        $gatewayName = $request->input('gateway', 'stripe');
        $gateway = $factory->create($gatewayName);

        $processor = new PaymentProcessor($gateway);
        $processor->processPayment($amount);
    }
}

// app/PaymentGatewayFactory.php

namespace App;

use App\StripePaymentGateway;
use App\PayPalPaymentGateway;
use App\AuthorizeNetPaymentGateway;

class PaymentGatewayFactory
{
    public function create($gatewayName = 'stripe')
    {
        switch ($gatewayName) {
            case 'paypal':
                return new PayPalPaymentGateway();
            case 'authorizenet':
                return new AuthorizeNetPaymentGateway();
            default:
                return new StripePaymentGateway();
        }
    }
}

In this example, we create a PaymentGatewayFactory class that encapsulates the creation of payment gateway instances. The create() method accepts a gateway name and returns an instance of the corresponding payment gateway class.

We then use this factory class in the PaymentController to create the payment gateway instance based on the gateway query parameter. If the gateway parameter is not present in the request, we default to using the Stripe payment gateway.

This approach makes it easy to add new payment gateways in the future. All we need to do is create a new payment gateway class and update the factory class to include the new gateway. The PaymentController and other parts of the application that use the factory class do not need to be modified.

Our factory class is still breaking the Open Close principle. There is a way we can make it more dynamic.

To improve the design, we can make use of PHP's reflection capability to dynamically discover and instantiate payment gateway classes.

Here's an updated implementation of the PaymentGatewayFactory class that uses reflection:

// app/PaymentGatewayFactory.php

namespace App;

use ReflectionClass;

class PaymentGatewayFactory
{
    public function create($gatewayName = 'stripe')
    {
        $gatewayClass = "App\\" . ucfirst($gatewayName) . "PaymentGateway";

        if (!class_exists($gatewayClass)) {
            throw new \InvalidArgumentException("Invalid gateway name: {$gatewayName}");
        }

        $reflection = new ReflectionClass($gatewayClass);
        if (!$reflection->isInstantiable()) {
            throw new \RuntimeException("Gateway class {$gatewayClass} cannot be instantiated");
        }

        return new $gatewayClass();
    }
}

In this updated implementation, we use the ReflectionClass class to dynamically discover and instantiate payment gateway classes based on their names. We first construct the fully qualified class name by concatenating the App\ namespace with the capital-cased gateway name and PaymentGateway suffix.

Next, we use class_exists() to check if the class exists, and throw an exception if it doesn't. We also check if the class is instantiable using the isInstantiable() method of ReflectionClass, and throw an exception if it's not.

Finally, we use the new operator to create an instance of the payment gateway class and return it.

With this updated implementation, we no longer need to modify the PaymentGatewayFactory class every time we add a new payment gateway. We can simply create a new payment gateway class and place it in the App namespace, and it will be automatically discoverable by the factory class. This improves the maintainability and extensibility of the application, while still adhering to the Open-Closed Principle.