Forem: Md Al Mustanjid

The Struggle of Code Reusability in Laravel: Why Traits Win the Race?

Md Al Mustanjid — Tue, 08 Apr 2025 10:02:11 +0000

The title has already conveyed so much. In web development with Laravel or a PHP environment, we often need to use the same method across multiple classes. Suppose we are creating a vehicle rental system that includes various types of vehicles. We can consider a base class named Vehicle, which can be extended to encompass different kinds of vehicles as child classes. So, here, inheritance is the solution? Let's see.

The Vehicle class serves as our parent class. It includes shared properties that all vehicles have, with the primary function being movement. In this parent class, we'll define these properties and the function as a method, creating a solid foundation for all vehicle types. We will rent cars, boats, and amphibious vehicles. Vehicles can have different capabilities:

Cars can only drive.
Boats can only sail.
Amphibious Vehicles can both drive and sail.

//Vehicle Class
namespace App\Models;

use Illuminate\Database\Eloquent\Model;


class Vehicle extends Model{
    protected $fillable = ['model', 'speed'];

    public function move(){
        return "{$this->model} is moving at {$this->speed} km/h.";
    }
}

Attempt: Using inheritance?

Now, all vehicles inherit this base class.

Car Class

namespace App\Models;

class Car extends Vehicle {
    public function drive() {
        return "{$this->model} is driving on land.";
    }
}

Boat Class

namespace App\Models;

class Boat extends Vehicle {
    public function sail() {
        return "{$this->model} is sailing on water.";
    }
}

But what are we gonna do for AmphibiousVehicle?

First, it can't inherit both Car and Boat classes together to get both functions, php doesn't support it. But, it can inherit from the vehicle class and implement both the drive and sail functions. We currently have duplicate drive( ) and sail( ) logic in two different classes. What's the issue? One thing! Have you noticed the repeated code? Here, we are creating DRY code. If we need modifications or changes, we will have to write the code twice!

Attempt: Using Interface?

Since multiple inheritance isn't possible, another option we can try is interface.

//Drive Interface

namespace App\Contracts;

interface Drivable {
    public function drive();
}

//Sail Interface

namespace App\Contracts;

interface Sailable {
    public function sail();
}

Implementing Interfaces in Car & Boat

//Car
namespace App\Models;

use App\Contracts\Drivable;

class Car extends Vehicle implements Drivable {
    public function drive() {
        return "{$this->model} is driving on land.";
    }
}

//Boat
namespace App\Models;

use App\Contracts\Sailable;

class Boat extends Vehicle implements Sailable {
    public function sail() {
        return "{$this->model} is sailing on water.";
    }
}

Now, let's implement AmphibiousVehicle using both interfaces.

namespace App\Models;

use App\Contracts\Drivable;
use App\Contracts\Sailable;

class AmphibiousVehicle extends Vehicle implements Drivable, Sailable {
    public function drive() {
        return "{$this->model} is driving on land.";
    }

    public function sail() {
        return "{$this->model} is sailing on water.";
    }
}

Wait, isn't this duplicate code? Interfaces don't solve code duplication! We still have to write the same logic in multiple places.

Ultimate Solution: Traits!

Okay, now we will explore the most important feature of the PHP environment, which is traits. A trait is a mechanism for reusing code across multiple classes without relying on traditional inheritance. It simplifies code reusability and facilitates easier sharing of behaviour. We will examine the usage of traits in depth later on.

Create Traits for Drive & Sail

//Drive Trait
namespace App\Traits;

//any vehicle drive on land will use this trait
trait DriveTrait{
    public function drive(){
        return "{$this->model} is driving on the land";
    }
}

//Sail Trait
namespace App\Traits;

//any vehicle sail on water will use this trait
trait SailTrait{
    public function sail(){
        return "{$this->model} is sailing on the water";
    }
}

Set Traits in Models

//Car
namespace App\Models;

use App\Traits\DriveTrait;
use App\Models\Vehicle;

class Car extends Vehicle{
    use DriveTrait;
}

//Boat
namespace App\Models;

use App\Traits\SailTrait;
use App\Models\Vehicle;

class Boat extends Vehicle{
    use SailTrait;
}

//AmphibiousVehicle
namespace App\Models;

use App\Traits\DriveTrait;
use App\Traits\SailTrait;
use App\Models\Vehicle;

class AmphibiousVehicle extends Vehicle{
    //Trait helps to share multiple behaviours at the same time easily
    use DriveTrait, SailTrait;
}

No more duplicate code! AmphibiousVehicle now inherits both!

Set a route and test our classes and traits.

use Illuminate\Support\Facades\Route;
use App\Models\Boat;
use App\Models\Car;
use App\Models\AmphibiousVehicle;

Route::get('/vehicles', function(){
    $car = new Car(['model' => 'Tesla', 'speed' => 150]);
    $boat = new Boat(['model' => 'Yamaha', 'speed' => 80]);
    $amphibious  = new AmphibiousVehicle(['model' => 'Hydra Spyder', 'speed' => 100]);

    return [
        'Car Drive' => $car->move().", ".$car->drive(),
        'Boat Sail' => $boat->move().", ".$boat->Sail(),
        'Amphibious Drive' => $amphibious->move().", ".$amphibious->drive(),
        'Amphibious Sail' => $amphibious->move().", ".$amphibious->sail(),
    ];
});

Get the source code here

Discover even more to uncover the essential traits that can make a difference.

Can a Trait have properties?

Yes, it should be in a function of a trait, not directly within a trait.

namespace App\Traits;

trait Logger {
    //$logPrefix = "[LOG]:"; // Error: props can't declare within trait

    public function logMessage($message){
        $logPrefix = "[LOG]:"; // set props inside a function
        return $logPrefix. $message;
    }
}

What happens if two Traits have methods with the same name in a class? How do you resolve conflicts?

To address conflicts in the same method between two traits, we can utilize either 'insteadof' or 'as'.

//Debugger Trait
namespace App\Traits;

trait Debugger{
    public function logMessage($message){
        return "Logging from Debugger:" . $message;
    }
}

////Logger Trait
namespace App\Traits;

trait Logger {
    public function logMessage($message){
        $logPrefix = "[LOG]:";
        return $logPrefix. $message;
    }
}

//LogService
namespace App\Services;
use App\Traits\Logger;
use App\Traits\Debugger;

class LogService{
    use Logger, Debugger
    { Debugger::logMessage insteadof Logger;
        Logger::logMessage as logFromLogger;
    }
}

Can a Trait use another Trait?

Yes.

Can Traits have constructors?

No. But, we can call a method from a trait in the constructor of the class.

trait LoggerTrait {
    public function setup() {
        echo "Logger is ready!\n";
    }
}

class Car {
    use LoggerTrait;

    public function __construct() {
        $this->setup(); // Calling the trait method
    }
}

Can Traits have abstract methods?

Yes, A trait can define abstract methods that must be implemented by the class using the trait.

Can Traits implement interfaces?

No, a trait cannot directly implement an interface. However, a class that incorporates a trait can implement an interface, allowing the methods from the trait to fulfill the contract of the interface.

interface Loggable {
    public function logMessage($message);
}

trait Logger {
    public function logMessage($message) {
        echo "Logging: $message";
    }
}

class AppService implements Loggable {
    use Logger; // This satisfies the Loggable interface
}

Can we restrict access modifiers in a Trait?

Yes, we can change the visibility of a method from a trait inside a class.

trait Logger {
    public function logMessage() {
        echo "Logging message";
    }
}

class App {
    use Logger {
        logMessage as private; // Now it's private in this class
    }
}

$app = new App();
$app->logMessage(); //Error: logMessage() is private

Happy coding!!!

Dependency Injection in Laravel: A Better Way to Manage Dependencies

Md Al Mustanjid — Sat, 15 Feb 2025 06:53:06 +0000

We all depend on something. From the moment we wake up, we rely on our alarm clock, coffee machine, or phone to start the day. Software systems are no different - they depend on services like databases, payment gateways, or email providers to function. But as applications grow, managing these dependencies becomes complex. Imagine building a notification system for an e-commerce app. Our initial implementation might look like this:

class NotificationService 
{
    public function send()
    {
        $emailService = new EmailService(); // Direct instantiation
        return $emailService->send("Welcome!");
    }
}

Here, the NotificationService is tightly coupled to EmailService. If we need a new notification method, we must modify NotificationService, making the code rigid and less maintainable.

This is where Dependency Injection (DI) comes in.

Dependency Injection (DI) and its types

Dependency injection (DI) is a design pattern where a class receives its required dependencies from other sources rather than creating them internally. DI also allows us to inject dependencies instead of hardcoding them into the class.

Types of Dependency Injection

Laravel supports four common types of dependency injection:

Constructor Injection
Method Injection
Binding
Contextual Binding

Before moving into the details of each injecting method, we prepare our project setup for implementing each one. Avoiding how to install the laravel project or something like that, assuming you have already done it.

Define the interface (Contract)

Create a new interfaces folder inside app and define a MessageService interface. So, any class going to implement it must have the send($msg) method.

app/Interfaces/MessageService.php

namespace App\Interfaces;
interface MessageService {
    public function send(string $message): string;
}

Create services (Implementations)

Inside app/Services, create implementations of MessageService.
Create another folder and name it as ‘services’. Here, we are going to put all message services individually. All services must implement the MessageServiceinterface. We will create two services, the first one is EmailService, and the second one is SMSService.

app/Services/EmailService.php

namespace App\Services;
use App\Interfaces\MessageService;
class EmailService implements MessageService {
    public function send($message) {
        return "Email: $message";
    }
}

app/Services/SmsService.php

namespace App\Services;
use App\Interfaces\MessageService;
class SMSService implements MessageService
{
    public function send($message)
    {
        return "SMS sent: " . $message;
    }
}

Create the `NotificationService`

Now, let's create a NotificationService inside the app/Services directory. This service will act as a bridge between our application and message services.
Instead of directly using an email or SMS service everywhere in our code, we use this NotificationService to keep things organized and flexible. This way, we can easily switch between different messaging services without changing our core logic.

app/Services/NotificationService.php

namespace App\Services;
use App\Interfaces\MessageService;
class NotificationService
{
    private $messageService;
    public function __construct(MessageService $messageService)
    {
        $this->messageService = $messageService;
    }
    public function send($message){
        return $this->messageService->send($message);
    }
}

Implementation of DI with laravel

Constructor Injection (Most Common)

The most commonly used way to inject dependencies in laravel. In this case, the dependency is passed through the constructor of a class and stored in a property for further use. It is best to use it for multiple dependencies and class-based uses.

class NotificationController extends Controller
{
    private $messageService;
    private $notifyService; //contextual binding

    //expects an instance of MessageService
    //When Laravel instantiates this controller, it automatically injects the bound implementation of MessageService
    /* thru this, we can send notifications without worrying about which 
    specific message service (Email or SMS) is being used */
    public function __construct(MessageService $messageService, NotifyService $notifyService)
    {
        $this->messageService = $messageService;
        $this->notifyService = $notifyService;
    }

    //return the response from the send method of the injected MessageService instance
    public function sendNotification(){
        return response()->json(
            [
                "Email with binding & constructor injection of DI" => $this->messageService->send("Emailed by constructor injection"),
                "SMS with contextual binding injection of DI" => $this->notifyService->send("SMS by contextual binding")
            ]
        );
    }

}

Method Injection

Instead of injecting the dependency in the constructor, we can inject it directly into a method. Laravel automatically resolves and injects services into the method when it's called. It is best to use when it is needed for a single time and dependency is only needed inside a single method. It also reduces unnecessary properties of a class.

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Interfaces\MessageService;
use GuzzleHttp\Psr7\Message;
use Mockery\Matcher\Not;
use App\Services\NotifyService;

class NotificationController extends Controller
{
    //Method Injection (MI)
    public function sendNotificationWithMI(MessageService $messageService)
    {
        return response()->json([
            'message' => $messageService->send("Emailed by Method Injection of DI")
        ]);
    }

}

Binding

To tell Laravel which implementation of MessageService to inject, we bind it inside the AppServiceProvider class of laravel. In future, if we need to switch sms service then just change it to sms. Register dependency bindings in the service provider.

namespace App\Providers;

use App\Interfaces\MessageService;
use Illuminate\Support\ServiceProvider;
use Illuminate\Validation\Rules\Email;
use App\Services\EmailService;
use App\Services\SMSService;
use Illuminate\Notifications\Notification;
use App\Services\NotifyService;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     */
    public function register(): void
    {
        // need to bind the MessageService interface to a concrete implementation (Email or Sms)
        // whenever MessageService is injected, Laravel will automatically provide an instance of EmailService.
        // if we change the binding to SMSService, Laravel will provide an instance of SMSService
        // just a simple modification in the bind method
        $this->app->bind(MessageService::class, EmailService::class);
    }

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        //
    }
}

Contextual Binding

Suppose, we need a single service but for different platforms with different sources. So, instead of setting in the right source each time, we can provide the correct one automatically based on where it is being used. Contextual binding allows us to use different parts of the application to use different implementations of the same interface without modifying the code. We can think of it using when different classes need different dependencies.

namespace App\Providers;

use App\Interfaces\MessageService;
use Illuminate\Support\ServiceProvider;
use Illuminate\Validation\Rules\Email;
use App\Services\EmailService;
use App\Services\SMSService;
use Illuminate\Notifications\Notification;
use App\Services\NotifyService;

class AppServiceProvider extends ServiceProvider
{
    /**
     * Register any application services.
     */
    public function register(): void
    {
        // need to bind the MessageService interface to a concrete implementation (Email or Sms)
        // whenever MessageService is injected, Laravel will automatically provide an instance of EmailService.
        // if we change the binding to SMSService, Laravel will provide an instance of SMSService
        // just a simple modification in the bind method
        $this->app->bind(MessageService::class, EmailService::class);

        //contextual binding: 
        //to setup specific implementation of an interface to inject only for a specific class.
        $this->app->when(NotifyService::class)
            ->needs(MessageService::class)
           ->give(SMSService::class);
    }

    /**
     * Bootstrap any application services.
     */
    public function boot(): void
    {
        //
    }
}

DI Comparison Table

DI Injection Methods	Implementation	Benefits
Constructor Injection	`NotificationService`, `NotificationController`	Best for class-wide dependencies, ensures consistency.
Method Injection	`sendNotification(MessageService $messageService)`	Best for one-time use, avoids unnecessary properties.
AppServiceProvider Binding	`$this->app->bind(MessageService::class, EmailService::class);`	Allows switching implementations without modifying code.
Contextual Binding	`$this->app->when(NotificationService::class)->needs(MessageService::class)->give(EmailService::class);`	Allows different classes to receive different implementations.

View Source Code on GitHub

Happy Coding!!!

Call/Pass by Value & Call/Pass by Reference in Js

Md Al Mustanjid — Tue, 11 Feb 2025 15:57:15 +0000

This calling thing is for js variables. There are two types of variables in js.

Primitive
Non-primitive/Reference

When working with js, we must have a sound knowledge of the differences between these two types. Call by value and Call by Reference can also be addressed as Pass by value and Pass by Reference respectively. Let’s see what are the primitive and non-primitive data in js. We will explore the features, calling, and passing process of these two variables and their differences.

Primitive	Non-primitive Data
Numbers	Array
Strings	Object
Boolean	Function
Null
Undefined
Bigint
Symbol

Primitive Data

In js, primitives are known as immutable data types;

that means we can’t change it once it has been created. If doing so, js will interact differently. Let’s see an example.

let name = 'Mustanjid';
console.log(name[1]) // output: u
//try to change the second letter of the name
name[1] = 'a' // not changed
console.log(name) // output: Mustanjid

It seems very uncommon with js strings. If we want to alter or change one string's alphabet, specifically if we want to change the value of a string, it will not happen as js doesn’t allow us to do that. In addition, we change the value of the string using methods such as toLowerCase, toUpperCase, etc. What was that? Actually, js returns a new string to us, not changing the value of the provided variable.

let nameWithUpperCase = name.toUpperCase();
console.log(nameWithUpperCase); // Output: MUSTANJID
console.log(name) // Output: Mustanjid

Calling/Passing by value in primitive data type

We commonly do this, by assigning the value of a variable to another variable. When it’s about primitive data types, then the value of the variable is called and copied in this case. They pass and remember through the value only.

let prevValue = 1;
let currValue = prevValue;
console.log(prevValue); // Output: 1
console.log(currValue); // Output: 1

Comparison of primitive data types

Comparison is also done by comparing values between two variables in the case of primitive data types. So, if the values are not the same then the comparison is false.

let name1 = 'Arif'
let name2 = 'Arif'
console.log(name1 === name2) // Output: true

Non-primitive Data Types

Most of the work in js is done by using functions (first-class function-based language), arrays, and objects. We can’t think of js without these three things. These three things are known and recognized as non-primitive data types. It is different from primitive as we can change the value after creating non-primitive data.

Non-primitive is mutable

When non-primitive data has been initialized, it creates an address in memory and remembers that to store data. It recalls the address to return the value following our needs (like stack and memory heap).

let arr = ['Js', 'React', 'Vue'];
let copyArr = arr;
console.log(arr); //Output: [ "Js", "React", "Vue" ]
console.log(copyArr); //Output: [ "Js", "React", "Vue" ]

Calling/Passing by Reference in Non-primitive data types

Is it possible that we’re not copying data!? it’s not a question actually. However, we already learned how non-primitive data types store data with an address. Copying between two objects or arrays is totally different in non-primitive cases. It copies the address eventually, the meaning of it is that

changing the value of an index in an array will also change the value of the copied array. Same for the object too

Let’s see an example to clear this in our minds.

    let arr = ['Js', 'React', 'Vue'];
    let copyArr = arr;
    console.log(arr); //Output: [ "Js", "React", "Vue" ]
    console.log(copyArr); //Output: [ "Js", "React", "Vue" ]

    //now let's change in the copy array and see what happens
    copyArr[1] = 'Angular';
    //it will also change in the main array
    console.log(arr); //Output: [ "Js", "Angular", "Vue" ]
    console.log(copyArr); //Output: [ "Js", "Angular", "Vue" ]

Comparison of non-primitive data types

Suppose, we want to compare values of two arrays or objects. Do we compare as we do in primitive types? Never

:::note
We do sometimes when arrays or objects are copied, see the example below
:::

! We compare through each index or property. So, having the same value doesn’t mean that comparison is the same.

let obj1 = {
  player: 'A'
}

let obj2 = {
  player: 'A'
}
console.log(obj1 === obj2) //output: false

But copied objects or arrays comparison will return true. See the example below.

let anObj = {
  name: 'Mustanjid'
}
let copyObj = anObj; //copied obj
console.log(anObj === copyObj) // Output: true

Let’s recap the major differences between these two data types.

Primitive	Non-Primitive
It is non-mutable.	It is mutable.
It saves data by value.	It saves data by address.
In comparison, the value of two variables is measured.	In comparison, the value of address between two variables is measured.

Now read the code below and determine what will be the output. Hope this writing helped you a little.

function passNonPrimitiveByRef (product) {
    product.name = 'Pen';
}

var aProductObj = {
  name: 'Book'
}
console.log(aProductObj.name) // Output: 
passNonPrimitiveByRef(aProductObj)
console.log(aProductObj.name) // Output: