Prinsip SOLID di Laravel — Satu per Satu dengan Contoh Nyata

Kalau kamu sudah paham OOP dasar dan mulai ngoding Laravel, cepat atau lambat kamu pasti ketemu kata “SOLID”.

Dan biasanya reaksinya satu dari dua hal: “Kedengarannya keren tapi aku nggak ngerti apa maksudnya”, atau “Aku hapal singkatannya tapi nggak tahu kapan pakainya.”

Artikel ini akan ngebahas semua lima prinsip — satu per satu, pakai contoh nyata dari aplikasi blog/CMS sederhana. Kamu akan lihat kode yang melanggar prinsipnya dulu, baru kita perbaiki. Karena menurut aku, cara tercepat paham “kenapa ini penting” adalah melihat sendiri apa yang rusak kalau kita abaikan.

Konteks Studi Kasus

Kita akan bangun fitur-fitur dari sebuah blog sederhana. Ada tiga entitas utama:

• Article — artikel yang ditulis penulis
• Comment — komentar dari pembaca
• User — penulis dan pembaca

Struktur tabelnya seperti ini:

users       → id, name, email, role
articles    → id, user_id, title, body, status, published_at
comments    → id, article_id, user_id, body, is_approved

Oke, kita mulai.

S — Single Responsibility Principle

“Satu kelas, satu alasan untuk berubah.”

Analoginya

Bayangin ada seorang tukang masak di restoran. Dia masak, dia juga yang cuci piring, sekaligus yang kasir, sekaligus yang anter makanan ke meja.

Kalau lagi rame, semua rusak sekaligus. Kalau mau ganti cara kasir (dari cash ke kartu), harus ganggu tukang masaknya dulu.

Itulah masalah kelas yang punya terlalu banyak tanggung jawab.

Kode yang Melanggar

Ini contoh ArticleController yang sering kelihatan di proyek pemula:

class ArticleController extends Controller
{
    public function store(Request $request)
    {
        // Validasi — harusnya bukan urusan controller
        $request->validate([
            'title'  => 'required|min:5',
            'body'   => 'required|min:50',
            'status' => 'required|in:draft,published',
        ]);

        // Logika bisnis — harusnya bukan urusan controller
        $article = Article::create([
            'user_id'      => auth()->id(),
            'title'        => $request->title,
            'body'         => $request->body,
            'status'       => $request->status,
            'published_at' => $request->status === 'published' ? now() : null,
        ]);

        // Notifikasi — harusnya JELAS bukan urusan controller
        Mail::to('editor@blog.com')->send(new ArticleSubmitted($article));

        return response()->json($article, 201);
    }
}

Sekarang tanya ke dirimu: berapa alasan kelas ini bisa berubah?

1. Kalau aturan validasi berubah
2. Kalau logika bisnis pembuatan artikel berubah
3. Kalau cara notifikasi berubah (dari email ke Slack misalnya)

Tiga alasan. Artinya tiga tanggung jawab. Ini melanggar SRP.

Kode yang Benar

Kita pisah tiap tanggung jawab ke file masing-masing.

📁 app/Http/Requests/StoreArticleRequest.php

Form Request khusus untuk validasi. Laravel punya fitur ini — manfaatkan.

<?php

namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;

class StoreArticleRequest extends FormRequest
{
    public function rules(): array
    {
        return [
            'title'  => 'required|min:5',
            'body'   => 'required|min:50',
            'status' => 'required|in:draft,published',
        ];
    }
}

📁 app/Services/ArticleService.php

Service untuk logika bisnis. Di sinilah “aturan main” fitur artikel tinggal.

<?php

namespace App\Services;

use App\Models\Article;
use App\Models\User;
use App\Notifications\ArticleSubmittedNotification;

class ArticleService
{
    public function create(array $data, User $author): Article
    {
        $article = Article::create([
            'user_id'      => $author->id,
            'title'        => $data['title'],
            'body'         => $data['body'],
            'status'       => $data['status'],
            'published_at' => $data['status'] === 'published' ? now() : null,
        ]);

        // Notifikasi jadi tanggung jawab service, bukan controller
        $author->notify(new ArticleSubmittedNotification($article));

        return $article;
    }
}

📁 app/Http/Controllers/ArticleController.php

Controller sekarang hanya “penghubung” — terima request, lempar ke service, kembalikan response.

<?php

namespace App\Http\Controllers;

use App\Http\Requests\StoreArticleRequest;
use App\Services\ArticleService;

class ArticleController extends Controller
{
    public function __construct(
        private ArticleService $articleService
    ) {}

    public function store(StoreArticleRequest $request): JsonResponse
    {
        // validated() sudah otomatis karena pakai Form Request
        $article = $this->articleService->create(
            $request->validated(),
            $request->user()
        );

        return response()->json($article, 201);
    }
}

📌 Sekarang kalau aturan validasi berubah, kamu hanya sentuh StoreArticleRequest. Kalau logika bisnis berubah, kamu hanya sentuh ArticleService. Controller tidak perlu diubah sama sekali.

O — Open/Closed Principle

“Terbuka untuk ditambah, tertutup untuk diubah.”

Analoginya

Bayangin colokan listrik di dinding. Kamu bisa colokkan apapun ke sana — charger HP, kipas, lampu. Colokannya tidak perlu diubah tiap kali kamu beli perangkat baru.

OCP prinsipnya sama: kelas yang sudah ada dan bekerja dengan baik tidak perlu disentuh ketika ada kebutuhan baru. Kamu cukup tambahkan kode baru, bukan ubah yang lama.

Kode yang Melanggar

Katakanlah kita punya fitur notifikasi ketika artikel dipublish. Kita tulis seperti ini:

class ArticlePublishedNotifier
{
    public function notify(Article $article, string $channel): void
    {
        if ($channel === 'email') {
            Mail::to($article->user)->send(new ArticlePublishedMail($article));
        } elseif ($channel === 'slack') {
            Http::post(config('services.slack.webhook'), [
                'text' => "Artikel baru: {$article->title}",
            ]);
        }
        // Besok kalau ada WhatsApp, harus tambah elseif lagi di SINI
        // Artinya kita UBAH kelas yang sudah jalan — berbahaya!
    }
}

Setiap kali ada channel notifikasi baru, kamu harus buka dan ubah file ini. Ini melanggar OCP.

Kode yang Benar

Kita pakai interface sebagai kontrak, lalu tiap channel jadi kelas sendiri.

📁 app/Contracts/ArticleNotificationChannel.php

<?php

namespace App\Contracts;

use App\Models\Article;

interface ArticleNotificationChannel
{
    public function send(Article $article): void;
}

📁 app/Notifications/Channels/EmailChannel.php

<?php

namespace App\Notifications\Channels;

use App\Contracts\ArticleNotificationChannel;
use App\Mail\ArticlePublishedMail;
use App\Models\Article;
use Illuminate\Support\Facades\Mail;

class EmailChannel implements ArticleNotificationChannel
{
    public function send(Article $article): void
    {
        Mail::to($article->user)->send(new ArticlePublishedMail($article));
    }
}

📁 app/Notifications/Channels/SlackChannel.php

<?php

namespace App\Notifications\Channels;

use App\Contracts\ArticleNotificationChannel;
use App\Models\Article;
use Illuminate\Support\Facades\Http;

class SlackChannel implements ArticleNotificationChannel
{
    public function send(Article $article): void
    {
        Http::post(config('services.slack.webhook'), [
            'text' => "Artikel baru dipublish: {$article->title}",
        ]);
    }
}

📁 app/Services/ArticlePublishedNotifier.php

Notifier tidak lagi tahu detail tiap channel — dia cukup loop dan panggil send().

<?php

namespace App\Services;

use App\Contracts\ArticleNotificationChannel;
use App\Models\Article;

class ArticlePublishedNotifier
{
    /** @param ArticleNotificationChannel[] $channels */
    public function __construct(
        private array $channels
    ) {}

    public function notify(Article $article): void
    {
        foreach ($this->channels as $channel) {
            $channel->send($article);
        }
    }
}

📌 Kalau besok kamu butuh notifikasi WhatsApp, kamu cukup buat WhatsAppChannel baru yang implements ArticleNotificationChannel. ArticlePublishedNotifier tidak perlu disentuh sama sekali. Terbuka untuk ditambah, tertutup untuk diubah.

L — Liskov Substitution Principle

“Subclass harus bisa menggantikan parent-nya tanpa bikin program rusak.”

Analoginya

Bayangin kamu punya remote TV. Semua remote TV — merek apapun — punya tombol Power, Volume, dan Channel. Kalau kamu ganti remote TV lama dengan yang baru, TV-nya harus tetap jalan normal.

Kalau remote baru tiba-tiba bikin TV meledak waktu kamu tekan Volume, itu masalahnya ada di remote — dia tidak bisa menggantikan tugasnya dengan benar.

LSP bilang: subclass tidak boleh “mengkhianati” janji yang sudah dibuat parent-nya.

Kode yang Melanggar

Kita punya abstract class BaseComment dan dua turunannya:

abstract class BaseComment
{
    abstract public function approve(): void;
    abstract public function getContent(): string;
}

class RegularComment extends BaseComment
{
    public function approve(): void
    {
        $this->is_approved = true;
        $this->save();
    }

    public function getContent(): string
    {
        return $this->body;
    }
}

// MASALAH DI SINI ↓
class SystemComment extends BaseComment
{
    public function approve(): void
    {
        // System comment tidak bisa di-approve — tapi parent-nya menjanjikan bisa!
        throw new \Exception("System comments cannot be approved.");
    }

    public function getContent(): string
    {
        return $this->message;
    }
}

Sekarang kalau ada kode seperti ini:

foreach ($comments as $comment) {
    $comment->approve(); // Meledak kalau $comment adalah SystemComment
}

SystemComment tidak bisa menggantikan BaseComment dengan aman — ini melanggar LSP.

Kode yang Benar

Solusinya: pisah kontrak menjadi lebih spesifik. Jangan paksa kelas mewarisi kemampuan yang tidak relevan untuknya.

📁 app/Contracts/ApprovableInterface.php

Hanya komentar yang bisa di-approve yang perlu implements ini.

<?php

namespace App\Contracts;

interface ApprovableInterface
{
    public function approve(): void;
    public function reject(): void;
}

📁 app/Models/Comment.php

<?php

namespace App\Models;

use App\Contracts\ApprovableInterface;
use Illuminate\Database\Eloquent\Model;

class Comment extends Model implements ApprovableInterface
{
    public function approve(): void
    {
        $this->update(['is_approved' => true]);
    }

    public function reject(): void
    {
        $this->update(['is_approved' => false]);
    }
}

📁 app/Models/SystemLog.php

Log sistem punya method-nya sendiri — tidak dipaksa punya approve().

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;

class SystemLog extends Model
{
    public function getContent(): string
    {
        return $this->message;
    }
    // Tidak ada approve() — karena memang tidak relevan
}

📌 Sekarang kode yang butuh fitur approve hanya akan menerima objek yang implements ApprovableInterface. Tidak ada lagi kemungkinan throw new Exception yang mengejutkan di tengah loop.

I — Interface Segregation Principle

“Jangan paksa kelas implement method yang tidak dia butuhkan.”

Analoginya

Bayangin ada formulir pendaftaran untuk karyawan baru. Di formulir itu ada pertanyaan: “Berapa lama kamu bisa menahan napas dalam air?”

Untuk programmer, pertanyaan itu tidak relevan sama sekali. Tapi mereka tetap harus isi karena formulirnya sama untuk semua orang.

ISP bilang: buat interface yang spesifik, bukan interface raksasa yang isinya terlalu banyak.

Kode yang Melanggar

Kita punya satu interface besar untuk semua aksi yang bisa dilakukan user di blog:

interface UserActionInterface
{
    public function writeArticle(): void;
    public function editArticle(): void;
    public function deleteArticle(): void;
    public function approveComment(): void;
    public function banUser(): void;        // Hanya admin yang bisa
    public function manageSettings(): void; // Hanya admin yang bisa
}

Sekarang kelas RegularAuthor dipaksa implement method yang tidak relevan:

class RegularAuthor implements UserActionInterface
{
    public function writeArticle(): void { /* oke */ }
    public function editArticle(): void { /* oke */ }
    public function deleteArticle(): void { /* oke */ }
    public function approveComment(): void { /* oke */ }

    // Dipaksa implement ini, padahal tidak masuk akal
    public function banUser(): void
    {
        throw new \Exception("Regular authors cannot ban users.");
    }

    public function manageSettings(): void
    {
        throw new \Exception("Regular authors cannot manage settings.");
    }
}

Kode yang Benar

Pecah interface besar tadi menjadi interface-interface kecil yang spesifik.

📁 app/Contracts/CanWriteArticle.php

<?php

namespace App\Contracts;

interface CanWriteArticle
{
    public function writeArticle(): void;
    public function editArticle(): void;
    public function deleteArticle(): void;
}

📁 app/Contracts/CanModerateContent.php

<?php

namespace App\Contracts;

interface CanModerateContent
{
    public function approveComment(): void;
    public function rejectComment(): void;
}

📁 app/Contracts/CanAdminister.php

<?php

namespace App\Contracts;

interface CanAdminister
{
    public function banUser(): void;
    public function manageSettings(): void;
}

Sekarang tiap role hanya implements apa yang relevan:

📁 app/Models/Author.php

<?php

namespace App\Models;

use App\Contracts\CanWriteArticle;

// Author hanya perlu CanWriteArticle — tidak ada method yang dipaksakan
class Author extends User implements CanWriteArticle
{
    public function writeArticle(): void { /* ... */ }
    public function editArticle(): void { /* ... */ }
    public function deleteArticle(): void { /* ... */ }
}

📁 app/Models/Admin.php

<?php

namespace App\Models;

use App\Contracts\CanAdminister;
use App\Contracts\CanModerateContent;
use App\Contracts\CanWriteArticle;

// Admin bisa melakukan semuanya — implements semua yang relevan
class Admin extends User implements CanWriteArticle, CanModerateContent, CanAdminister
{
    public function writeArticle(): void { /* ... */ }
    public function editArticle(): void { /* ... */ }
    public function deleteArticle(): void { /* ... */ }
    public function approveComment(): void { /* ... */ }
    public function rejectComment(): void { /* ... */ }
    public function banUser(): void { /* ... */ }
    public function manageSettings(): void { /* ... */ }
}

📌 Author tidak tahu soal banUser(). Admin punya segalanya. Dan kalau besok kamu buat role Moderator yang cuma bisa moderasi komentar, kamu tinggal implements CanModerateContent saja — tanpa mewarisi method yang tidak perlu.

D — Dependency Inversion Principle

“Kelas bergantung pada abstraksi, bukan pada implementasi konkret.”

Analoginya

Bayangin lampu di rumahmu. Lampu itu tidak “bergantung” pada PLN secara langsung. Dia bergantung pada colokan listrik — sebuah standar abstrak.

Karena itu, kamu bisa pasang solar panel di rumah, dan lampunya tetap nyala tanpa perlu ganti lampunya. Yang berubah hanya sumber listriknya — bukan lampunya.

DIP bilang: kelas kamu harus bergantung pada interface/abstraksi, bukan pada class konkret tertentu. Karena kalau langsung bergantung pada implementasi, ganti implementasi = ubah semua kode yang bergantung padanya.

Kode yang Melanggar

CommentService langsung bergantung pada implementasi konkret database:

class CommentService
{
    // Langsung bikin object Eloquent di dalam service
    // Artinya CommentService "tahu" dan bergantung pada Eloquent
    public function getUnapprovedComments(): Collection
    {
        return Comment::where('is_approved', false)->get();
    }

    public function approve(int $commentId): void
    {
        $comment = Comment::findOrFail($commentId);
        $comment->update(['is_approved' => true]);
    }
}

Masalahnya: kalau kamu mau test CommentService tanpa database sungguhan, tidak bisa. Dan kalau besok kamu ganti cara ambil data (misalnya dari cache atau API), kamu harus ubah CommentService langsung.

Kode yang Benar

Kita buat interface sebagai “colokan” — lalu CommentService bergantung pada interface itu, bukan pada Eloquent.

📁 app/Contracts/CommentRepositoryInterface.php

<?php

namespace App\Contracts;

use Illuminate\Support\Collection;

interface CommentRepositoryInterface
{
    public function getUnapproved(): Collection;
    public function approve(int $commentId): void;
    public function findOrFail(int $commentId): mixed;
}

📁 app/Repositories/EloquentCommentRepository.php

Implementasi konkret yang menggunakan Eloquent.

<?php

namespace App\Repositories;

use App\Contracts\CommentRepositoryInterface;
use App\Models\Comment;
use Illuminate\Support\Collection;

class EloquentCommentRepository implements CommentRepositoryInterface
{
    public function getUnapproved(): Collection
    {
        return Comment::where('is_approved', false)->get();
    }

    public function approve(int $commentId): void
    {
        $comment = $this->findOrFail($commentId);
        $comment->update(['is_approved' => true]);
    }

    public function findOrFail(int $commentId): Comment
    {
        return Comment::findOrFail($commentId);
    }
}

📁 app/Services/CommentService.php

Service sekarang bergantung pada interface, bukan Eloquent langsung.

<?php

namespace App\Services;

use App\Contracts\CommentRepositoryInterface;
use Illuminate\Support\Collection;

class CommentService
{
    // Bergantung pada ABSTRAKSI (interface), bukan implementasi konkret
    public function __construct(
        private CommentRepositoryInterface $commentRepository
    ) {}

    public function getUnapprovedComments(): Collection
    {
        return $this->commentRepository->getUnapproved();
    }

    public function approve(int $commentId): void
    {
        $this->commentRepository->approve($commentId);
    }
}

📁 app/Providers/AppServiceProvider.php

Di sinilah kita “sambungkan” interface ke implementasinya — satu baris binding.

public function register(): void
{
    $this->app->bind(
        \App\Contracts\CommentRepositoryInterface::class,
        \App\Repositories\EloquentCommentRepository::class
    );
}

📌 Sekarang kalau kamu mau test CommentService, tinggal buat FakeCommentRepository yang implements interface yang sama — tanpa sentuh database sungguhan. Dan kalau kamu mau ganti ke cache atau API, cukup ganti satu baris di AppServiceProvider. CommentService tidak perlu tahu apa yang berubah.

🗺️ Gambaran Besar — Semuanya Bersama

Ini bagaimana semua file dari kelima prinsip duduk di struktur Laravel:

app/
├── Contracts/
│   ├── ArticleNotificationChannel.php   ← OCP: kontrak channel notifikasi
│   ├── ApprovableInterface.php          ← LSP: kontrak untuk yang bisa di-approve
│   ├── CanWriteArticle.php              ← ISP: kontrak spesifik per kemampuan
│   ├── CanModerateContent.php           ← ISP
│   ├── CanAdminister.php                ← ISP
│   └── CommentRepositoryInterface.php   ← DIP: kontrak repository
│
├── Http/
│   ├── Controllers/
│   │   └── ArticleController.php        ← SRP: hanya urusan HTTP
│   └── Requests/
│       └── StoreArticleRequest.php      ← SRP: hanya urusan validasi
│
├── Services/
│   ├── ArticleService.php               ← SRP: logika bisnis artikel
│   ├── ArticlePublishedNotifier.php     ← OCP: kirim ke semua channel
│   └── CommentService.php              ← DIP: bergantung pada interface
│
├── Repositories/
│   └── EloquentCommentRepository.php   ← DIP: implementasi konkret
│
├── Notifications/
│   └── Channels/
│       ├── EmailChannel.php             ← OCP: channel spesifik
│       └── SlackChannel.php             ← OCP: channel spesifik
│
└── Models/
    ├── Comment.php                      ← LSP: implements ApprovableInterface
    ├── Author.php                       ← ISP: hanya CanWriteArticle
    └── Admin.php                        ← ISP: semua kemampuan

🧭 Ringkasan — SOLID dalam Satu Kalimat

💡 Ingat!

Waktu pertama kali belajar SOLID, wajar kalau rasanya “ribet banget, bikin interface segitu banyak untuk hal sesederhana ini?”

Jawabannya: untuk aplikasi kecil, memang tidak perlu semua ini. Tapi begitu timmu tumbuh, fiturnya bertambah, dan kamu harus ganti library payment atau tambah channel notifikasi — kamu akan sangat bersyukur sudah punya abstraksi yang jelas.

SOLID bukan tentang menulis lebih banyak kode. Ini tentang menulis kode yang mudah diganti tanpa takut merusak hal lain. Di dunia nyata, itu nilainya sangat besar.