دیزاین پترن ها در لاراول

در دنیای توسعه وب، استفاده از چارچوب‌های مختلف برای تسریع و تسهیل فرآیند توسعه وب‌سایت‌ها بسیار معمول است. لاراول یکی از فریمورک های محبوب در زمینه توسعه وب است که توسط بسیاری از توسعه‌دهندگان در سراسر جهان استفاده می‌شود. یکی از عوامل کلیدی در توسعه هر پروژه، استفاده از الگوها یا دیزاین پترن‌ها است. در این مقاله به بررسی اهمیت و کاربردهای دیزاین پترن‌ها در لاراول می‌پردازیم.

دیزاین پترن‌ها چیست؟

مشکلات تکراری توسعه نرم افزار را می توان از طریق دیزاین پترن‌ها حل کرد. آنها به عنوان دستورالعملی برای نوشتن کدهای سازمان یافته و قابل استفاده مجدد عمل می کنند. دیزاین پترن‌ها در زمینه لاراول مجموعه ای از اصول و بهترین شیوه ها را به برنامه نویسان ارائه می دهد که تولید برنامه های کاربردی با کیفیت بالا را تضمین می کند.

در اینجا برخی از الگوهای طراحی رایج مورد استفاده در لاراول آورده شده است:

The Builder (Manager) pattern
The need for the Builder (Manager) pattern
The Factory pattern
The need for the Factory pattern
The Repository pattern
The need for the Repository pattern
The Strategy pattern -The need for the Strategy pattern
The Provider pattern
The Facade pattern
The Architectural Model-View-Controller Pattern

بیاید تک تک آن ها را بررسی کنیم.

الگوی MVC

لاراول به طور قابل توجهی از الگوی طراحی Model-View-Controller (MVC) استفاده می کند که یک اصل کلیدی طراحی است. این برنامه نرم افزار را به سه بخش مرتبط تقسیم می کند:

Model : مدل نمایش داده ها و منطق تجاری برنامه است. این شامل کلیه قوانین و اعتبار سنجی های تجاری و همچنین رویه های دسترسی و دستکاری داده ها می باشد. مدل‌ها اغلب در لاراول به‌عنوان کلاس‌هایی توسعه می‌یابند که با پایگاه داده اصلی یا سایر منابع داده ارتباط برقرار می‌کنند.

View: لایه نمایش و رابط کاربری توسط view مدیریت می شود. مشخص می کند که دید کاربر از داده های برنامه چگونه باید باشد. در لاراول، view معمولاً به صورت قالب‌های Blade ساخته می‌شوند که به خروجی HTML یک سینتکس قوی و گویا می‌دهد.

کنترلر: بین مدل و View، کنترلر به عنوان یک واسطه عمل می کند. به پرسش‌های کاربر پاسخ می‌دهد، پردازش داده‌ها را مدیریت می‌کند و در صورت لزوم View را تازه می‌کند. از طریق درخواست‌های HTTP، کنترلرها ورودی کاربر را دریافت می‌کنند، با مدل کار می‌کنند تا داده‌ها را دریافت یا تغییر دهند، و سپس نتایج را برای ارائه به view تحویل دهند. در لاراول، کنترلرها به‌عنوان کلاس‌هایی پیاده‌سازی می‌شوند که روش‌های مختلفی را در راستای فعالیت‌ها یا مسیرهای برنامه خاص مشخص می‌کنند.

پوشه اصلی پروژه
|
├── پوشه‌های مدل (Model)
│   ├── User
│   ├── Post
│   └── ...
│
├── پوشه‌های ویو (View)
│   ├── user
│   │   ├── index.blade.php
│   │   ├── create.blade.php
│   │   └── ...
│   ├── post
│   │   ├── index.blade.php
│   │   ├── show.blade.php
│   │   └── ...
│   └── ...
│
├── پوشه‌های کنترلر (Controller)
│   ├── UserController.php
│   ├── PostController.php
│   └── ...
│
├── فایل‌های مسیرها (Routes)
│   ├── web.php
│   ├── api.php
│   └── ...
│
├── پوشه‌های مهاجرت‌ها (Migrations)
│   ├── 2023_09_01_create_users_table.php
│   ├── 2023_09_02_create_posts_table.php
│   └── ...
│
├── پوشه فایل‌های عمومی (Public Files)
│   ├── images
│   ├── css
│   ├── js
│   └── ...
│
└── پوشه‌های فایل‌های پیکربندی (Config Files)
    ├── database.php
    ├── app.php
    └── ...

معماری حال حاضر لاراول:

پوشه‌ی ریشه (Root Directory)
│
├── app
├── ├── Http
│   │	├── Controllers
│   │	│   ├── Controller1.php
│  	│	│   ├── Controller2.php
│  	│	│   └── ...
│   │	├── Middleware
│   │	│   ├── Middleware1.php
│   │	│   ├── Middleware2.php
│   │	│   └── ...
│   │	└── Requests
│   │    	├── Request1.php
│   │    	├── Request2.php
│   │    	└── ...
│	├── Providers
│   │	├── Provider1.php
│  	│ 	├── Provider2.php
│   │	└── ...
│	├── Console
│	├── Commands
│   ├── Command1.php
│   ├── Command2.php
│   └── ...
│	└── Kernel.php
│	├── Models
│	├── Model1.php
│	├── Model2.php
│	└── ...
│
├── bootstrap: کدها و تنظیمات مربوط به بوت استرپ فریم‌ورک
│	
├── config: تنظیمات برنامه
│
├── database: مدیریت میاگرشن و داده‌های پایگاه داده
│	├── factories: فابریکتورها برای ایجاد داده‌های تست
│	├── migrations: مایگرشن ها برای مدیریت ساختار پایگاه داده
│	├── seeders: سیدرها برای پر کردن داده‌های تست
│
├── public: فایل‌ها قابل دسترسی عمومی (CSS، JS، تصاویر)
│
├── resources: منابع مرتبط با ویوها و ترجمه‌ها
│   ├── lang: فایل‌های زبانی
│   ├── views: فایل‌های ویو
│
├── routes: تعریف مسیرها و مسیریابی
│
├── storage: ذخیره‌سازی فایل‌های آپلود شده و داده‌های سیستمی
│   ├── app: فایل‌های تولید شده توسط برنامه
│   ├── framework: فایل‌های سیستمی فریم‌ورک
│   ├── logs: فایل‌های لاگ برنامه
│
├── vendor: کد‌های وابسته به پکیج‌های استفاده شده در برنامه
├
├──.env
├
└──...

الگوی Repository 

یکی دیگر از الگوهای طراحی مفید در لاراول الگوی Repository است. بین منطق تجاری و منبع داده برنامه، لایه ای از آبسترک را ارائه می دهد. با کپسوله کردن منطق دسترسی به داده ها و عایق بندی بقیه برنامه از ویژگی های ذخیره سازی داده های زیرین، Repository به عنوان یک پل عمل می کند.

استفاده از الگوی Repository شما را قادر می سازد منطق دسترسی به داده های خود را متمرکز کنید و جابجایی بین چندین منبع داده (مانند پایگاه داده ها و API ها) را ساده تر کنید. توانایی ساخت Repository ساختگی برای تست واحد، این الگو را قابل تست تر می کند.

در زیر پوشه بندی از این الگو داریم:

پوشه اصلی پروژه
|
├── پوشه‌های مدل‌ها (Models)
│   ├── User.php
│   ├── Post.php
│   └── ...
│
├── پوشه‌های ریپازیتوری (Repositories)
│   ├── UserRepository.php
│   ├── PostRepository.php
│   └── ...
│
├── پوشه‌های ویو‌ها (Views)
│   ├── user
│   │   ├── index.blade.php
│   │   ├── create.blade.php
│   │   └── ...
│   ├── post
│   │   ├── index.blade.php
│   │   ├── show.blade.php
│   │   └── ...
│   └── ...
│
├── پوشه‌های کنترلرها (Controllers)
│   ├── UserController.php
│   ├── PostController.php
│   └── ...
│
├── پوشه‌های مسیرها (Routes)
│   ├── web.php
│   ├── api.php
│   └── ...
│
├── پوشه‌های مایگرشن ها(Migrations)
│   ├── 2023_09_01_create_users_table.php
│   ├── 2023_09_02_create_posts_table.php
│   └── ...
│
├── پوشه فایل‌های عمومی (Public Files)
│   ├── images
│   ├── css
│   ├── js
│   └── ...
│
└── پوشه‌های فایل‌های پیکربندی (Config Files)
    ├── database.php
    ├── app.php
    └── ...

الگوی Factory 

الگوی Factory راهی برای آسان کردن ایجاد اشیا است. در لاراول، اغلب با Dependency Injection برای کمک به ایجاد اشیاء پیچیده استفاده می شود.

استفاده از الگوی Factory به شما این امکان را می دهد که فرآیند ایجاد اشیاء را از کدی که از آنها استفاده می کند جدا کنید. این کار تغییر اشیاء خاصی را که استفاده می کنید بدون نیاز به تغییر کدهای زیادی آسان تر می کند.

به طور کلی، الگوی Factory کمک می کند تا کد شما را انعطاف پذیرتر و ماژولارتر کند و ایجاد شی را ساده تر و سازماندهی کرده است.

پوشه اصلی پروژه
|
├── پوشه‌های مدل (Model)
│   ├── User
│   ├── Post
│   └── ...
│
├── پوشه‌های کنترلر (Controller)
│   ├── UserController.php
│   ├── PostController.php
│   └── ...
│
├── پوشه‌های مهاجرت‌ها (Migrations)
│   ├── 2023_09_01_create_users_table.php
│   ├── 2023_09_02_create_posts_table.php
│   └── ...
│
├── پوشه فایل‌های عمومی (Public Files)
│   ├── images
│   ├── css
│   ├── js
│   └── ...
│
├── پوشه‌های فایل‌های پیکربندی (Config Files)
│   ├── database.php
│   ├── app.php
│   └── ...
│
├── پوشه‌های فکتوری (Factories)
│   ├── UserFactory.php
│   ├── PostFactory.php
│   └── ...
│
└── ...

در این شماتیک، پوشه های فکتوری (Factory) به عنوان یک بخش مهم از یک پروژه لاراول نمایش داده شده است. این پوشه‌ها برای تولید داده‌های نمونه (فیک) برای مدل‌های شما استفاده می‌شوند. به عنوان مثال، UserFactory.php برای تولید داده‌های نمونه برای مدل کاربر به کار می‌رود.

Model Factory در لاراول به توسعه‌دهندگان اجازه می‌دهد تا به راحتی داده‌های آزمایشی و نمونه‌هایی را برای مدل‌های خود ایجاد کنند و از آنها در محیط‌های توسعه و آزمایش استفاده کنند.

الگوی سینگلتون

اطمینان از اینکه یک کلاس فقط یک نمونه در کل برنامه دارد با رویکرد Singleton لاراول امکان پذیر است. مدیریت منابع مشترک یا تنظیمات گلوبال یکی از کاربردهای مکرر آن است.

با استفاده از طرح Singleton می توانید دسترسی به این منابع مشترک را از یک منطقه مرکزی مدیریت کنید. زیرا برای این امر از ایجاد مصداق خارجی جلوگیری می شود. علاوه بر این، انتقال داده ها بین بخش های برنامه شما را ساده می کند و کارایی و سازگاری را ارتقا می دهد.

در لاراول، الگوی Singleton، که تضمین می‌کند تنها یک نمونه از یک کلاس وجود دارد، به شما کمک می‌کند تا با اطمینان از سازگاری داده‌ها در سراسر برنامه‌تان و مدیریت منابع مشترک، سازماندهی کنید.

شماتیک این الگو به صورت زیر می باشد:

پوشه اصلی پروژه
|
├── پوشه‌های مدل (Model)
│   ├── User
│   ├── Post
│   └── ...
│
├── پوشه‌های کنترلر (Controller)
│   ├── UserController.php
│   ├── PostController.php
│   └── ...
│
├── فایل‌های مسیرها (Routes)
│   ├── web.php
│   ├── api.php
│   └── ...
│
├── پوشه‌های مایگرشن ها(Migrations)
│   ├── 2023_09_01_create_users_table.php
│   ├── 2023_09_02_create_posts_table.php
│   └── ...
│
├── پوشه‌های فایل‌های عمومی (Public Files)
│   ├── images
│   ├── css
│   ├── js
│   └── ...
│
└── پوشه‌های فایل‌های پیکربندی (Config Files)
    ├── database.php
    ├── app.php
    └── ...

در مدل پوشه‌بندی Singleton، تفاوت اصلی با مدل پوشه‌بندی MVC این است که نیازی به پوشه‌های ویو و مدل نیست. این مدل بیشتر برای ساختارهایی مناسب است که نیاز به ایجاد نمونه تکی از یک کلاس دارند، مانند اتصال به پایگاه داده یا مدیریت تنظیمات.

در این مدل، کنترلرها و مایگرشن ها همچنان حضور دارند و برای مدیریت عملیات وب و پایگاه داده مورد استفاده قرار می‌گیرند. همچنین، فایل‌های عمومی و فایل‌های پیکربندی نیز در پروژه وجود دارند.این مدل برای مواردی که نیاز به اشتراک داده‌ها و منابع است، بسیار مفید است

الگوی Observer 

اشیاء می توانند در رویدادها مشترک شوند و هنگامی که آن رویدادها با استفاده از الگوی Observer لاراول راه اندازی می شوند، اعلان دریافت کنند. اشیایی که اعلان ها را ارسال می کنند و اشیایی که آنها را دریافت می کنند را می توان با استفاده از این تکنیک از هم جدا کرد.

قبل از اینکه بتوانید از الگوی Observer استفاده کنید، ابتدا باید یک کلاس Observer در لاراول بسازید. رابط Observer که دارای یک متد به نام ()update است توسط این کلاس پیاده سازی خواهد شد. هر بار که رویدادی که ناظر در آن مشترک شده است راه اندازی شود، متد ()update فراخوانی می شود.

هنگامی که یک کلاس Observer ایجاد شد، ممکن است در توزیع کننده رویداد لاراول ثبت شود. شما می توانید با فراخوانی متد ()attach رویداد Dispatcher و ارائه کلاس Observer به عنوان پارامتر به این امر دست یابید.

هنگامی که یک رویداد راه اندازی می شود، توزیع کننده رویداد به طور خودکار متد ()update را روی همه ناظران مشترک فراخوانی می کند. این به ناظران اجازه می دهد تا بر اساس رویدادی که رخ داده واکنش نشان داده و اقدامات مناسب را انجام دهند.

شماتیکی از این الگو به صورت زیر می باشد:

پوشه اصلی پروژه
|
├── پوشه‌های مدل (Model)
│   ├── User
│   ├── Post
│   └── ...
│
├── پوشه‌های مشاهده‌گرها (Observers)
│   ├── UserObserver.php
│   ├── PostObserver.php
│   └── ...
│
├── پوشه‌های کنترلر (Controller)
│   ├── UserController.php
│   ├── PostController.php
│   └── ...
│
├── فایل‌های مسیرها (Routes)
│   ├── web.php
│   ├── api.php
│   └── ...
│
├── پوشه‌های مهاجرت‌ها (Migrations)
│   ├── 2023_09_01_create_users_table.php
│   ├── 2023_09_02_create_posts_table.php
│   └── ...
│
├── پوشه فایل‌های عمومی (Public Files)
│   ├── images
│   ├── css
│   ├── js
│   └── ...
│
└── پوشه‌های فایل‌های پیکربندی (Config Files)
    ├── database.php
    ├── app.php
    └── ...

در این تقسیم‌بندی، پوشه‌های "مدل" شامل مدل‌های داده‌ای پروژه هستند، پوشه‌های "Observer" شامل فایل‌های Observer هستند که تغییرات در مدل‌ها را مشاهده و پیگیری می‌کنند.

مدل پوشه‌بندی Observer به توسعه‌دهندگان امکان می‌دهد به راحتی رویدادها و تغییرات در مدل‌ها را مدیریت کنند و اقدامات مختلفی را به تغییرات واکنش دهند. این یک رویکرد مفید برای پیاده‌سازی قابلیت‌های مشابه به رویدادها در لاراول است.

در اینجا مثالی از نحوه استفاده از الگوی Observer در لاراول آورده شده است:

class UserObserver implements Observer
{
    public function update(Model $model)
    {
        if ($model->isDirty('email')) {
            // Send an email to the user notifying them of their new email address.
        }
    }
}

$eventDispatcher->attach(User::class, new UserObserver());

// Trigger an event to notify the observers that a user's email address has been changed.
$user->email = 'new@email.com';
$user->save();

در این کد ها ، کلاسی به نام UserObserver به عنوان مکانیزم اطلاع رسانی برای ناظران زمانی که کاربر آدرس ایمیل خود را تغییر می دهد، عمل می کند. تابع ()update در کلاس UserObserver هر بار که رویداد متصل به User::class فعال می شود فراخوانی می شود. این به ناظر این امکان را می دهد که با انجام اقداماتی مانند ارسال ایمیل به کاربر برای اطلاع از آدرس ایمیل به روز شده خود به رویداد واکنش نشان دهد.

الگوی استراتژی

برای جدا کردن رفتار یک شی از اجرای آن در لاراول، از الگوی استراتژی، یک الگوی طراحی رفتاری استفاده کنید. این امر ماژولار بودن و قابلیت استفاده مجدد کد را افزایش می دهد و تغییر رفتار یک شی را در زمان اجرا ساده تر می کند.

استراتژی‌های مختلف کش اغلب در لاراول با استفاده از الگوی استراتژی اجرا می‌شوند. به عنوان مثال، کلاس IlluminateCacheRepository بسیاری از استراتژی‌های کش، مانند کش کردن فایل‌ها و حافظه پنهان پایگاه داده را با استفاده از الگوی Strategy پیاده‌سازی می‌کند.

برای استفاده از طراحی استراتژی لاراول ابتدا باید خانواده ای از الگوریتم ها را تعریف کنید. رابط یکسان باید توسط هر الگوریتم پیاده سازی شود. گام بعدی ساختن یک شی زمینه است که به یک نمونه الگوریتم خاص اشاره دارد. شیء الگوریتم کاری را که توسط شیء زمینه تفویض شده بود تکمیل می کند.

شماتیکی از پوشه بندی این پترن به صورت زیر می باشد:

پوشه اصلی پروژه
|
├── پوشه‌های الگوهای استراتژی (Strategies)
│   ├── Strategy1
│   │   ├── Strategy1.php
│   │   └── ...
│   ├── Strategy2
│   │   ├── Strategy2.php
│   │   └── ...
│   └── ...
│
├── کلاس مدیر استراتژی (Strategy Manager)
│   ├── StrategyManager.php
│   └── ...
│
├── کلاس کلاینت (Client)
│   ├── Client.php
│   └── ...
│
└── ...

در پوشه‌های "الگوهای استراتژی"، هر استراتژی به عنوان یک زیرپوشه آماده می‌شود. هر زیرپوشه شامل فایل‌های مربوط به یک استراتژی خاص است.
به عنوان مثال، "Strategy1" و "Strategy2" نمونه‌های مختلف از استراتژی‌ها هستند.
پوشه "Strategy Manager" حاوی کلاس‌های مدیریت استراتژی است که مسئول انتخاب و اجرای استراتژی‌ها توسط مشتریان هستند.
پوشه "کلاس کلاینت" حاوی کلاس‌های کلاینت است که از استراتژی‌ها برای انجام عملیات خاصی استفاده می‌کنند.
سایر پوشه‌ها و فایل‌ها نیز برای سایر بخش‌های پروژه و تنظیمات مورد نیاز استفاده می‌شوند.

این تقسیم‌بندی به توسعه‌دهندگان کمک می‌کند تا الگوی استراتژی را به بهترین شکل در پروژه خود پیاده‌سازی کنند و از ترتیب و منظمی در کدها بهره‌برند.

در اینجا مثالی از نحوه استفاده از الگوی Strategy در لاراول برای پیاده سازی استراتژی های مختلف کش آورده شده است:

interface CacheStrategy
{
    public function cache(string $key, $value);
}

class FileCacheStrategy implements CacheStrategy
{
    public function cache(string $key, $value)
    {
        // Cache the value in a file.
    }
}

class DatabaseCacheStrategy implements CacheStrategy
{
    public function cache(string $key, $value)
    {
        // Cache the value in the database.
    }
}

class CacheContext
{
    private $cacheStrategy;

    public function __construct(CacheStrategy $cacheStrategy)
    {
        $this->cacheStrategy = $cacheStrategy;
    }

    public function cache(string $key, $value)
    {
        return $this->cacheStrategy->cache($key, $value);
    }
}

$cacheContext = new CacheContext(new FileCacheStrategy());
$cacheContext->cache('key', 'value');

// ...

رابط CacheStrategy در این کد ها رابط استاندارد را برای تمام تکنیک های کش تعریف می کند. کلاس های FileCacheStrategy و DatabaseCacheStrategy رابط CacheStrategy را پیاده سازی می کنند و چندین پیاده سازی استراتژی کش را ارائه می دهند. یکی از الگوریتم های کش با یک مرجع در کلاس CacheContext نشان داده می شود. شی استراتژی ذخیره سازی که در واقع ذخیره سازی را انجام می دهد، توسط کلاس زمینه کش به این وظیفه داده می شود.

الگوی Facades 

رابط یک زیرسیستم پیچیده توسط الگوی Facades ساده و یکپارچه می شود. این پیچیدگی اساسی را پنهان می کند و یک رابط کاربری ساده ارائه می دهد تا مشتریان بتوانند با زیرسیستم ارتباط برقرار کنند.

با کمک استفاده گسترده لاراول از طراحی Facades ، می توانید با استفاده از واژگان مختصر و رسا به عناصر چارچوب مختلف دسترسی پیدا کنید. منحنی یادگیری برای مهندسان جدید با این تکنیک کاهش می یابد، که خوانایی کد را بهبود می بخشد.

قبل از اینکه بتوانید از الگوی Facades استفاده کنید، ابتدا باید Facades مورد نظر را به لاراول وارد کنید. به عنوان مثال، برای استفاده از Facades Cache، کد زیر را وارد کنید:

use Illuminate\Support\Facades\Cache;
Cache::put('key', 'value', 10);

در زیر شماتیکی از پوشه بندی الگوی Facades می بینید:

پوشه اصلی پروژه
|
├── پوشه‌های مدل (Model)
│   ├── User
│   ├── Post
│   └── ...
│
├── پوشه‌های ویو (View)
│   ├── user
│   │   ├── index.blade.php
│   │   ├── create.blade.php
│   │   └── ...
│   ├── post
│   │   ├── index.blade.php
│   │   ├── show.blade.php
│   │   └── ...
│   └── ...
│
├── پوشه‌های کنترلر (Controller)
│   ├── UserController.php
│   ├── PostController.php
│   └── ...
│
├── فایل‌های مسیرها (Routes)
│   ├── web.php
│   ├── api.php
│   └── ...
│
├── پوشه‌های مایگرشن ها(Migrations)
│   ├── 2023_09_01_create_users_table.php
│   ├── 2023_09_02_create_posts_table.php
│   └── ...
│
├── پوشه فایل‌های عمومی (Public Files)
│   ├── images
│   ├── css
│   ├── js
│   └── ...
│
├── پوشه‌های فایل‌های پیکربندی (Config Files)
│   ├── database.php
│   ├── app.php
│   └── ...
│
├── پوشه Facades
│   ├── MyCustomFacade.php
│   ├── AnotherFacade.php
│   └── ...
│
└── ...

در این شماتیک، پوشه Facades برای نگهداری فاساد‌ها (Facades) و کلاس‌های مرتبط با آنها استفاده می‌شود. Facades در لاراول برای دسترسی به سرویس‌ها و کلاس‌های مختلف درون اپلیکیشن به صورت یک رابط ساده و فراخوانی آسان تعریف می‌شوند. این تقسیم‌بندی به توسعه‌دهندگان امکان می‌دهد تا از Facades در پروژه‌های خود استفاده کنند و به راحتی به سرویس‌ها و قابلیت‌های مختلف دسترسی داشته باشند.

الگوی آداپتور

یک الگوی طراحی ساختاری به نام Adapter این امکان را برای اجزای با رابط های متفاوت فراهم می کند. این الگو اغلب زمانی اعمال می شود که یک شی موجود که می خواهید از آن استفاده کنید دارای یک رابط است که با رابط مورد نیاز شما ناسازگار است.

طراحی آداپتور اغلب در لاراول برای ادغام با APIهای خارجی استفاده می شود.

به عنوان مثال، ادغام با بسیاری از API های HTTP با استفاده از کلاس GuzzleHttpClient امکان پذیر است. کلاس GuzzleHttpClient از نظر رابط با کلاینت API Laravel متفاوت است. کلاس GuzzleHttpClient را می توان برای کار با رابط کلاینت API Laravel با استفاده از کلاس GuzzleAdapter تغییر داد.

ابتدا باید یک کلاس آداپتور ایجاد کنید تا از الگوی Adapter در لاراول استفاده کنید. رابط مورد نیاز شما توسط کلاس آداپتور پیاده سازی می شود. پس از آن، کلاس آداپتور وظیفه را به شیئی که در حال تطبیق می باشد، اختصاص می دهد.

در اینجا مثالی از نحوه استفاده از الگوی Adapter در لاراول برای ادغام با یک API شخص ثالث آورده شده است:

interface ApiClient
{
    public function get(string $url);
}

class GuzzleAdapter implements ApiClient
{
    private $client;

    public function __construct(GuzzleHttp\Client $client)
    {
        $this->client = $client;
    }

    public function get(string $url)
    {
        return $this->client->get($url);
    }
}

$client = new GuzzleAdapter(new GuzzleHttp\Client());
$response = $client->get('https://example.com/api/v1/users');

GuzzleAdapter رابط ApiClient را در این کد های بالا پیاده سازی می کند. پس از آن، کلاس GuzzleAdapter وظیفه را به کلاس GuzzleHttpClient منتقل می کند.

برخی از مزایای استفاده از طراحی آداپتور در لاراول به شرح زیر است:

• ادغام با APIهای خارجی توسط این امر تسهیل می شود.
   
• ماژولار بودن و قابلیت استفاده مجدد کد را افزایش می دهد.
   
• ممکن است عملکرد برنامه شما توسط آن افزایش یابد.
   

در زیر چند مورد از معایب استفاده از طراحی آداپتور در لاراول آورده شده است:

• ممکن است شفافیت کد را کاهش دهد.
   
• اشکال زدایی کد می تواند چالش برانگیز باشد.
   
• ممکن است حفظ کد را سخت‌تر کند.

نمونه ای از شماتیک پوشه بندی این دیزاین پترن به صورت زیر می باشد:

پوشه اصلی پروژه
|
├── پوشه‌های مدل (Model)
│   ├── Adapter
│   │   ├── ThirdPartyLibraryAdapter.php
│   │   └── ...
│   ├── Client.php
│   ├── TargetInterface.php
│   └── ...
│
├── پوشه‌های کنترلر (Controller)
│   ├── MainController.php
│   └── ...
│
├── فایل‌های مسیرها (Routes)
│   ├── web.php
│   └── ...
│
├── پوشه‌های فایل‌های عمومی (Public Files)
│   ├── images
│   ├── css
│   ├── js
│   └── ...
│
└── پوشه‌های فایل‌های پیکربندی (Config Files)
    ├── database.php
    ├── app.php
    └── ...

در پوشه‌ی Model، یک زیرپوشه به نام Adapter ایجاد شده است. این زیرپوشه شامل کلاس‌های مربوط به Adapter است که وظیفه تبدیل رابط کلاینت به رابط کتابخانه‌ی شخص‌ ثالث (Third Party) را دارند. به عنوان مثال، کلاس ThirdPartyLibraryAdapter.php نمونه‌ای از یک Adapter است.

در پوشه‌ی Model نیز کلاس‌های Client.php و TargetInterface.php وجود دارند. کلاس Client.php نماینده‌ی کلاینت است که نیاز به تعامل با کتابخانه‌ی شخص‌سومی دارد. کلاس TargetInterface.php نیز رابطی است که کلاینت انتظار دارد از کتابخانه داشته باشد.

در سایر بخش‌ها نیز می‌توانید کنترلرها، مسیرها، فایل‌های عمومی و فایل‌های پیکربندی را مانند هر پروژه‌ای که با لاراول توسعه می‌دهید، مدیریت کنید.

مزایای الگوهای طراحی چیست؟
 

قابلیت استفاده مجدد کد: الگوهای طراحی استفاده مجدد از کد را تشویق می کند و به شما امکان می دهد از راه حل های فعلی استفاده کنید و کدهای تکراری را کاهش دهید. این باعث بهبود خروجی و کاهش زمان توسعه می شود.

مقیاس پذیری: وقتی از الگوهای طراحی استفاده می کنید، پایگاه کد شما مدولار و همه کاره می شود. همانطور که نیازهای شما تغییر می کند، می توانید به سرعت برنامه خود را تطبیق داده و مقیاس دهید.

سازماندهی کد: الگوهای طراحی به کد شما کمک می کنند ساختار واضحی داشته باشد که درک و نگهداری آن را ساده تر می کند. این منجر به کار تیمی بهتر و رفع اشکال سریعتر می شود.

قابلیت نگهداری: با پیروی از الگوهای طراحی، می توانید مطمئن شوید که کد شما به خوبی سازماندهی شده و استانداردهای فعلی را رعایت می کند. این کار تعمیر و نگهداری را آسان تر می کند و احتمال اضافه کردن باگ را کاهش می دهد.

نتیجه

الگوهای طراحی ممکن است به طور چشمگیری کیفیت کلی، عملکرد و قابلیت نگهداری پایگاه کد شما را هنگام ایجاد برنامه های لاراول بهبود بخشند. الگوهای طراحی منابع مفیدی هستند که پاسخ های آزمایش شده ای را برای مشکلات معمول در توسعه نرم افزار ارائه می دهند. در حالی که الگوهای طراحی دارای مزایای بسیاری هستند، مهم است که به یاد داشته باشید که آنها راه حلی بی‌خطر برای هر مشکلی نیستند. قبل از تعیین الگوهای طراحی برای استفاده، مهم است که الزامات خاص برنامه خود را به دقت ارزیابی کنید.