Namespace dan Autoloading

Setiap berkas Laravel yang kita buka selalu diawali dua hal: deklarasi namespace di bagian atas dan baris-baris use ... setelahnya. Kedua mekanisme ini menjawab masalah klasik proyek besar: bagaimana membedakan class User milik model aplikasi kita dari class User milik library lain, dan bagaimana memuat ratusan berkas tanpa menulis require satu per satu. Memahami namespace dan autoloading membuat perintah seperti php artisan make:model Post tidak lagi terasa seperti sihir.

Apa Itu Namespace #

Namespace adalah cara memberi nama “alamat” bagi class agar tidak saling bertabrakan. Deklarasi namespace App\Models; di awal berkas menyatakan bahwa semua class, interface, dan trait di berkas tersebut hidup di dalam ruang bernama App\Models. Nama lengkapnya (fully qualified name) menjadi App\Models\User — mirip nama file yang disusun folder demi folder:

<?php

namespace App\Models;

class User
{
    public static function namaKelas(): string
    {
        return self::class;
    }
}

Berkas kedua boleh mendefinisikan class bernama User juga, selama ruang namanya berbeda. Di proyek nyata kita bahkan menemukan dua class User sekaligus: App\Models\User milik aplikasi dan Illuminate\Foundation\Auth\User milik framework — keduanya hidup berdampingan tanpa konflik karena alamatnya berbeda.

use dan Aliasing #

Menulis nama lengkap Illuminate\Support\Facades\Route setiap kali memanggil facade jelas tidak praktis. Keyword use mengimpor class ke lingkup berkas saat itu sehingga cukup ditulis Route. Dua contoh berikut menunjukkan use beraksi pada program PHP murni:

<?php

require __DIR__ . '/App/Models/User.php';
require __DIR__ . '/App/Http/User.php';

use App\Models\User;
use App\Http\User as UserResource;

echo User::namaKelas() . "\n";
echo UserResource::namaKelas() . "\n";
echo App\Http\User::namaKelas() . "\n";

Output yang Dihasilkan:

App\Models\User
App\Http\User
App\Http\User

Program di atas memuat dua berkas yang masing-masing berisi class User — satu di namespace App\Models dan satu di App\Http. Baris use App\Models\User; membuat User di dalam berkas ini merujuk versi model, sedangkan use App\Http\User as UserResource; mengimpor versi kedua dengan nama alias UserResource. Baris terakhir menunjukkan bahwa nama lengkap tanpa use juga sah dipakai kapan saja.

Konstanta ::class #

Konstanta ajaib ::class mengembalikan nama lengkap sebuah class sebagai string — berguna saat framework meminta nama class, misalnya untuk mendaftarkan policy atau middleware alias. Pada kode Laravel kita sering menulis User::class alih-alih string 'App\Models\User' karena editor bisa mengecek ejaannya dan refactor bisa mengikutinya secara otomatis.

PSR-4 dan Autoloading Composer #

Sekarang pertanyaan besar chapter sebelumnya: dari mana PHP tahu lokasi berkas sebuah class? Standar PSR-4 menjawabnya dengan aturan sederhana — nama namespace dipetakan ke struktur folder. Composer, sebagai dependency manager PHP, membaca peta tersebut lalu mendaftarkan autoloader: fungsi yang otomatis menjalankan require berkas yang tepat saat sebuah class pertama kali dipakai.

Peta tersebut didefinisikan di composer.json. Berikut potongan asli dari proyek sandbox Course ini:

{
    "autoload": {
        "psr-4": {
            "App\\": "app/",
            "Database\\Factories\\": "database/factories/",
            "Database\\Seeders\\": "database/seeders/"
        }
    },
    "autoload-dev": {
        "psr-4": {
            "Tests\\": "tests/"
        }
    }
}

Baris "App\\": "app/" berarti setiap class dengan namespace berawalan App\ dicari di dalam folder app/. Sisa nama setelah awalan menjadi jalur berkas:

Aturan ini dua arah: class App\Models\User wajib berada di app/Models/User.php, dan berkas app/Models/Post.php yang berisi class bernama hal lain akan membuat autoloader gagal menemukannya.

Autoloading dalam Praktik #

Mari kita buktikan mekanismenya di sandbox. Pertama, kita buat berkas baru app/Support/Penyapa.php — class PHP biasa tanpa ketergantungan framework, diletakkan sesuai aturan PSR-4:

<?php

namespace App\Support;

class Penyapa
{
    public function __construct(
        protected string $bahasa = 'id',
    ) {
    }

    public function sapa(string $nama): string
    {
        return match ($this->bahasa) {
            'en' => "Hello, {$nama}!",
            default => "Halo, {$nama}!",
        };
    }
}

Kedua, kita jalankan runner yang memakai class tersebut. Satu-satunya require di seluruh program hanyalah vendor/autoload.php — tidak ada satu baris pun yang memuat app/Support/Penyapa.php secara manual:

<?php
$dir = $argv[1];
require $dir.'/vendor/autoload.php';
$app = require $dir.'/bootstrap/app.php';
$app->make(Illuminate\Contracts\Console\Kernel::class)->bootstrap();

use App\Support\Penyapa;

$penyapa = new Penyapa();
$penyapaEn = new Penyapa('en');

echo $penyapa->sapa('Budi') . "\n";
echo $penyapaEn->sapa('Siti') . "\n";
echo Penyapa::class . "\n";

Output yang Dihasilkan:

Halo, Budi!
Hello, Siti!
App\Support\Penyapa

Autoloader Composer-lah yang memuat berkas app/Support/Penyapa.php tepat saat baris new Penyapa() dieksekusi. Ketika kita nanti menjalankan php artisan make:model Post, artisan hanya membuat berkas app/Models/Post.php dengan namespace App\Models — autoload sudah menang sisanya tanpa konfigurasi tambahan.

Dokumentasi lengkap mengenai Composer beserta siklus autoloading-nya tersedia di getcomposer.org , sedangkan daftar folder bawaan aplikasi Laravel 13 dan isinya bisa dibaca di dokumentasi struktur direktori .

Sejauh ini kita memahami bagaimana kode aplikasi Laravel saling menemukan satu sama lain. Namun bagaimana framework itu sendiri — paket laravel/framework berukuran ratusan megabyte di folder vendor/ — sampai berada di sana? Itu pekerjaan Composer dan sistem dependency-nya, topik chapter berikutnya.