در برنامه‌نویسی PHP و Laravel، معمولاً در ابتدای پروژه می‌توانیم با چند Controller، تعدادی Model و چند سرویس ساده، قابلیت‌های مورد نیاز را پیاده‌سازی کنیم. اما با گسترش برنامه، اضافه شدن امکاناتی مانند چند درگاه پرداخت، انواع روش‌های ارسال کالا، سرویس‌های پیامکی و APIهای خارجی، ساختار کد اهمیت بیشتری پیدا می‌کند.
اگر برای هر قابلیت جدید مجبور باشیم چندین کلاس موجود را تغییر دهیم، احتمال ایجاد خطا افزایش پیدا می‌کند و نگهداری پروژه دشوارتر می‌شود.
یکی از راهکارهای حل این مسئله، استفاده از Design Pattern یا الگوهای طراحی نرم‌افزار است.
الگوهای طراحی، راه‌حل‌های شناخته‌شده‌ای برای مسائل تکرارشونده در طراحی نرم‌افزار هستند. این الگوها کد آماده‌ای نیستند که بدون تغییر در هر پروژه استفاده شوند؛ بلکه روش‌هایی برای سازمان‌دهی کلاس‌ها، مدیریت وابستگی‌ها و ارتباط بین بخش‌های مختلف برنامه ارائه می‌کنند.
در این مقاله یاد می‌گیریم Design Pattern چیست، چه تفاوتی با اصول SOLID دارد و چگونه چهار الگوی کاربردی Strategy، Factory، Adapter و Observer را در پروژه‌های Laravel پیاده‌سازی کنیم.
برای مثال‌ها از یک فروشگاه اینترنتی استفاده می‌کنیم تا کاربرد هر الگو را در شرایط واقعی ببینیم.
Design Pattern چیست؟
Design Pattern به یک الگوی شناخته‌شده برای حل یک مسئله رایج در طراحی نرم‌افزار گفته می‌شود.
برای مثال، فرض کنید فروشگاه شما در ابتدا فقط از درگاه زرین‌پال استفاده می‌کند؛ اما بعداً تصمیم می‌گیرید درگاه سداد و به‌پرداخت را نیز اضافه کنید.
اگر تمام منطق درگاه‌ها را در یک Controller قرار داده باشید، احتمالاً برای اضافه کردن هر درگاه باید همان Controller را تغییر دهید.
در مقابل، اگر ساختار برنامه را طوری طراحی کنید که هر درگاه پیاده‌سازی مستقلی داشته باشد و فرایند پرداخت با یک قرارداد مشترک کار کند، اضافه کردن درگاه جدید آسان‌تر خواهد بود.
این مسئله نمونه‌ای از موقعیت‌هایی است که استفاده از الگوهای طراحی می‌تواند مفید باشد.
دسته‌بندی الگوهای طراحی
الگوهای طراحی کلاسیک معمولاً در سه گروه قرار می‌گیرند:
| دسته | کاربرد | نمونه‌ها |
|---|---|---|
| Creational | مدیریت ایجاد اشیا | Factory، Builder، Singleton |
| Structural | سازمان‌دهی ارتباط بین کلاس‌ها و اجزا | Adapter، Decorator، Facade |
| Behavioral | مدیریت رفتار و ارتباط بین اشیا | Strategy، Observer، Command، State |
این دسته‌بندی به درک بهتر الگوها کمک می‌کند؛ اما هر الگو الزاماً فقط در یک نوع معماری یا فریم‌ورک کاربرد ندارد.
در ادامه، چهار الگوی پرکاربرد را با مثال‌های Laravel بررسی می‌کنیم.
۱. الگوی Strategy در Laravel
الگوی Strategy زمانی کاربرد دارد که چند روش متفاوت برای انجام یک عملیات داشته باشیم و بخواهیم روش مناسب را بدون تغییر منطق اصلی انتخاب کنیم.
برای مثال، در فروشگاه اینترنتی ممکن است چند روش پرداخت داشته باشیم:
- پرداخت با زرین‌پال
- پرداخت با سداد
- پرداخت با به‌پرداخت
تمام این درگاه‌ها وظیفه مشترکی دارند: اجرای فرایند پرداخت. اما جزئیات درخواست، احراز اصالت پاسخ و تأیید تراکنش آن‌ها متفاوت است.
به‌جای اینکه تمام این منطق را در یک کلاس با شرط‌های متعدد بنویسیم، می‌توانیم از Strategy استفاده کنیم.
مرحله اول: تعریف قرارداد پرداخت
فایل app/Contracts/PaymentGateway.php را ایجاد کنید:
<?php
namespace App\Contracts;
interface PaymentGateway
{
public function pay(int $amount): string;
}
در این مثال، متد pay() مبلغ را دریافت می‌کند و یک شناسه یا آدرس پیگیری پرداخت را به‌صورت رشته برمی‌گرداند.
این قرارداد برای ساده نگه داشتن مثال است. درگاه واقعی معمولاً به اطلاعاتی مانند شناسه سفارش، آدرس بازگشت، اطلاعات پرداخت‌کننده و داده‌های مخصوص ارائه‌دهنده نیز نیاز دارد.
مرحله دوم: ساخت Strategy اول
فایل app/Services/Payment/ZarinpalGateway.php:
<?php
namespace App\Services\Payment;
use App\Contracts\PaymentGateway;
class ZarinpalGateway implements PaymentGateway
{
public function pay(int $amount): string
{
// درخواست واقعی به API زرین‌پال
// و دریافت اطلاعات انتقال کاربر
return 'zarinpal-payment-reference';
}
}
این کلاس مسئول اجرای فرایند پرداخت از طریق زرین‌پال است.
مقدار بازگشتی در مثال بالا صرفاً نمایشی است و جایگزین پاسخ واقعی درگاه نمی‌شود.
مرحله سوم: ساخت Strategy دوم
فایل app/Services/Payment/SadadGateway.php:
<?php
namespace App\Services\Payment;
use App\Contracts\PaymentGateway;
class SadadGateway implements PaymentGateway
{
public function pay(int $amount): string
{
// درخواست واقعی به API سداد
// و دریافت اطلاعات انتقال کاربر
return 'sadad-payment-reference';
}
}
هر دو کلاس یک قرارداد مشترک را پیاده‌سازی می‌کنند؛ اما منطق داخلی آن‌ها مستقل است.
مرحله چهارم: استفاده از Strategy در سرویس پرداخت
فایل app/Services/CheckoutService.php:
<?php
namespace App\Services;
use App\Contracts\PaymentGateway;
class CheckoutService
{
public function __construct(
protected PaymentGateway $gateway
) {}
public function checkout(int $amount): string
{
return $this->gateway->pay($amount);
}
}
کلاس CheckoutService نیازی ندارد بداند پرداخت با زرین‌پال انجام می‌شود یا سداد. کافی است یک پیاده‌سازی معتبر از PaymentGateway دریافت کند.
برای نمونه، می‌توانیم در AppServiceProvider پیاده‌سازی پیش‌فرض را ثبت کنیم:
use App\Contracts\PaymentGateway;
use App\Services\Payment\ZarinpalGateway;
public function register(): void
{
$this->app->bind(
PaymentGateway::class,
ZarinpalGateway::class
);
}
اکنون Laravel هنگام حل وابستگی PaymentGateway، کلاس ZarinpalGateway را تزریق می‌کند.
نکته مهم: این Binding یک پیاده‌سازی پیش‌فرض تعیین می‌کند. اگر کاربر بتواند هنگام خرید بین چند درگاه انتخاب کند، باید انتخاب Strategy را نیز پیاده‌سازی کنیم. در بخش بعد، این کار را با Factory انجام می‌دهیم.
چه زمانی از Strategy استفاده کنیم؟
Strategy زمانی مفید است که چند الگوریتم یا روش اجرایی برای یک وظیفه مشترک داریم؛ مانند:
- روش‌های پرداخت
- محاسبه هزینه ارسال
- محاسبه تخفیف
- روش‌های قیمت‌گذاری
- روش‌های ارسال اعلان
اگر فقط یک روش ثابت داریم و احتمال توسعه نیز پایین است، ممکن است نیازی به ایجاد چند کلاس و Interface نباشد.
۲. الگوی Factory در Laravel
Factory Pattern برای متمرکز کردن منطق ساخت اشیا استفاده می‌شود.
گاهی می‌دانیم چند پیاده‌سازی برای یک قابلیت داریم، اما نمی‌خواهیم کلاس اصلی مسئول انتخاب و ساخت آن‌ها باشد.
برای مثال، در فروشگاه اینترنتی، کاربر ممکن است یکی از درگاه‌های زرین‌پال یا سداد را انتخاب کند. می‌توانیم کلاسی داشته باشیم که بر اساس نام درگاه، پیاده‌سازی مناسب را برگرداند.
در این مثال از Strategyهای بخش قبل استفاده می‌کنیم.
مرحله اول: ایجاد PaymentGatewayFactory
فایل app/Services/Payment/PaymentGatewayFactory.php:
<?php
namespace App\Services\Payment;
use App\Contracts\PaymentGateway;
use InvalidArgumentException;
class PaymentGatewayFactory
{
public function make(string $gateway): PaymentGateway
{
return match ($gateway) {
'zarinpal' => app(ZarinpalGateway::class),
'sadad' => app(SadadGateway::class),
default => throw new InvalidArgumentException(
'Unsupported payment gateway.'
),
};
}
}
این Factory نام درگاه را دریافت می‌کند و نمونه مناسب را برمی‌گرداند.
در Laravel، تابع app() از Service Container برای حل وابستگی‌ها استفاده می‌کند. به همین دلیل، اگر کلاس درگاه خودش وابستگی‌های دیگری داشته باشد، Container می‌تواند آن‌ها را نیز تأمین کند.
مرحله دوم: استفاده از Factory
حالا می‌توانیم یک سرویس برای اجرای پرداخت بنویسیم:
<?php
namespace App\Services;
use App\Services\Payment\PaymentGatewayFactory;
class CheckoutService
{
public function __construct(
protected PaymentGatewayFactory $factory
) {}
public function checkout(
string $gateway,
int $amount
): string {
$paymentGateway = $this->factory->make($gateway);
return $paymentGateway->pay($amount);
}
}
برای نمونه، فراخوانی سرویس با مقدار zarinpal باعث انتخاب ZarinpalGateway می‌شود و مقدار sadad پیاده‌سازی دوم را انتخاب می‌کند.
در این ساختار، مسئولیت انتخاب درگاه از کلاس CheckoutService جدا شده است.
آیا این Factory برای پروژه واقعی کافی است؟
برای مثال آموزشی مناسب است؛ اما در پروژه عملی باید چند نکته را در نظر بگیرید:
- نام درگاه باید از تنظیمات معتبر یا انتخاب کنترل‌شده کاربر دریافت شود.
- نباید به انتخاب درگاه از سمت کاربر اعتماد کرد، بدون آنکه مجاز بودن آن بررسی شود.
- مبلغ پرداخت باید در سمت سرور محاسبه و اعتبارسنجی شود.
- وضعیت پرداخت باید پس از تأیید معتبر درگاه ثبت شود.
- درخواست پرداخت نباید صرفاً با برگشت کاربر به سایت، موفق تلقی شود.
همچنین، در پروژه‌های بزرگ‌تر می‌توان به‌جای شرط‌های داخل Factory از یک Registry یا ساختار مبتنی بر تنظیمات استفاده کرد؛ اما چنین پیچیدگی‌ای باید متناسب با نیاز واقعی پروژه باشد.
تفاوت Factory و Strategy
این دو الگو اغلب در کنار یکدیگر استفاده می‌شوند، اما یکسان نیستند.
- Strategy روش‌های مختلف اجرای یک عملیات را از یکدیگر جدا می‌کند.
- Factory مسئول انتخاب یا ایجاد شیء مناسب است.
در مثال ما، ZarinpalGateway و SadadGateway دو Strategy هستند و PaymentGatewayFactory وظیفه انتخاب آن‌ها را بر عهده دارد.
۳. الگوی Adapter در Laravel
الگوی Adapter زمانی کاربرد دارد که بخواهیم از یک کلاس یا سرویس استفاده کنیم، اما رابط آن با چیزی که برنامه ما انتظار دارد متفاوت باشد.
این الگو به‌خصوص در اتصال به APIهای خارجی بسیار مفید است.
فرض کنید برنامه ما از یک قرارداد مشترک برای ارسال پیامک استفاده می‌کند، اما سرویس پیامکی انتخاب‌شده متدها و پارامترهای مخصوص خودش را دارد.
به‌جای آنکه منطق اختصاصی سرویس پیامکی را در تمام بخش‌های برنامه پخش کنیم، می‌توانیم یک Adapter بنویسیم.
مرحله اول: تعریف قرارداد ارسال پیامک
فایل app/Contracts/SmsSender.php:
<?php
namespace App\Contracts;
interface SmsSender
{
public function send(
string $phone,
string $message
): bool;
}
این قرارداد مشخص می‌کند برنامه ما برای ارسال پیامک به چه عملیاتی نیاز دارد.
مرحله دوم: ساخت Adapter برای API خارجی
فرض کنید یک کلاس واسط برای API پیامکی داریم که متد sendMessage() را با ساختار پارامترهای مخصوص خودش ارائه می‌کند.
فایل app/Services/Sms/ProviderSmsAdapter.php:
<?php
namespace App\Services\Sms;
use App\Contracts\SmsSender;
class ProviderSmsAdapter implements SmsSender
{
public function __construct(
protected SmsProviderClient $client
) {}
public function send(
string $phone,
string $message
): bool {
$response = $this->client->sendMessage([
'mobile' => $phone,
'text' => $message,
]);
return $response->isSuccessful();
}
}
در این مثال، SmsProviderClient یک کلاس فرضی برای ارتباط با سرویس پیامکی است و باید در پروژه واقعی بر اساس SDK یا API ارائه‌دهنده پیاده‌سازی شود.
کار Adapter تبدیل رابط مورد انتظار برنامه به رابط مورد نیاز سرویس خارجی است.
مرحله سوم: اتصال Adapter به Service Container
در AppServiceProvider، قرارداد را به Adapter متصل می‌کنیم:
use App\Contracts\SmsSender;
use App\Services\Sms\ProviderSmsAdapter;
public function register(): void
{
$this->app->bind(
SmsSender::class,
ProviderSmsAdapter::class
);
}
اکنون سرویس‌های دیگر برنامه می‌توانند فقط به SmsSender وابسته باشند.
برای مثال:
<?php
namespace App\Services;
use App\Contracts\SmsSender;
class OrderNotificationService
{
public function __construct(
protected SmsSender $smsSender
) {}
public function sendOrderConfirmation(
string $phone
): bool {
return $this->smsSender->send(
$phone,
'سفارش شما با موفقیت ثبت شد.'
);
}
}
کلاس OrderNotificationService از جزئیات API پیامکی اطلاعی ندارد. اگر ارائه‌دهنده پیامک تغییر کند، می‌توانیم Adapter دیگری بسازیم و Binding را تغییر دهیم؛ بدون آنکه منطق اصلی اعلان سفارش را بازنویسی کنیم.
تفاوت Adapter با Strategy
هر دو الگو می‌توانند با Interface و چند پیاده‌سازی همراه باشند، اما هدف آن‌ها متفاوت است.
Strategy برای انتخاب بین روش‌های مختلف انجام یک کار به کار می‌رود. Adapter رابط یک سیستم را به رابط مورد انتظار سیستم دیگر تبدیل می‌کند.
برای مثال، انتخاب میان چند روش محاسبه تخفیف معمولاً به Strategy نزدیک است؛ اما سازگار کردن SDK یک ارائه‌دهنده پیامک با قرارداد داخلی برنامه، نمونه‌ای از Adapter است.
۴. الگوی Observer در Laravel
الگوی Observer زمانی کاربرد دارد که پس از رخ دادن یک رویداد، بخش‌های دیگری از برنامه باید از آن مطلع شوند.
فرض کنید کاربر در فروشگاه اینترنتی سفارش جدیدی ثبت می‌کند. پس از ثبت سفارش ممکن است لازم باشد:
- ایمیل تأیید سفارش ارسال شود.
- پیامک اطلاع‌رسانی فرستاده شود.
- آمار فروش به‌روزرسانی شود.
- یک پیام برای سیستم حسابداری ارسال شود.
اگر تمام این عملیات را داخل متد ثبت سفارش قرار دهیم، کلاس سفارش به بخش‌های مختلف سیستم وابسته می‌شود.
با استفاده از رویدادها، می‌توانیم این بخش‌ها را از منطق اصلی سفارش جدا کنیم.
Laravel سیستم Event و Listener دارد که یکی از کاربردهای آن، پیاده‌سازی الگوی Observer است.
مرحله اول: ایجاد Event
در ترمینال پروژه اجرا کنید:
php artisan make:event OrderPlaced
این دستور کلاس رویداد را ایجاد می‌کند.
فایل app/Events/OrderPlaced.php را به شکل زیر تکمیل کنید:
<?php
namespace App\Events;
use App\Models\Order;
use Illuminate\Foundation\Events\Dispatchable;
use Illuminate\Queue\SerializesModels;
class OrderPlaced
{
use Dispatchable;
use SerializesModels;
public function __construct(
public Order $order
) {}
}
این رویداد، سفارش ثبت‌شده را در اختیار Listenerها قرار می‌دهد.
مرحله دوم: ایجاد Listener
برای ارسال ایمیل، Listener ایجاد کنید:
php artisan make:listener SendOrderConfirmation
فایل app/Listeners/SendOrderConfirmation.php:
<?php
namespace App\Listeners;
use App\Events\OrderPlaced;
use Illuminate\Support\Facades\Mail;
class SendOrderConfirmation
{
public function handle(OrderPlaced $event): void
{
$order = $event->order;
Mail::raw(
'سفارش شما با شماره '
. $order->id
. ' ثبت شد.',
function ($message) use ($order) {
$message->to($order->user->email)
->subject('تأیید سفارش');
}
);
}
}
این Listener هنگام دریافت رویداد OrderPlaced، ایمیل تأیید را ارسال می‌کند.
برای استفاده واقعی، بهتر است از تنظیمات صحیح Mail، قالب ایمیل و مدیریت خطا استفاده کنید. در برنامه‌هایی که ارسال ایمیل نباید پاسخ درخواست را کند کند، می‌توان Listener را به صف ارسال کرد.
مرحله سوم: انتشار رویداد پس از ثبت سفارش
در سرویس ثبت سفارش، پس از ایجاد موفق سفارش می‌توانیم رویداد را منتشر کنیم:
use App\Events\OrderPlaced;
use App\Models\Order;
use Illuminate\Support\Facades\DB;
public function createOrder(array $data): Order
{
$order = DB::transaction(function () use ($data) {
return Order::create($data);
});
OrderPlaced::dispatch($order);
return $order;
}
این مثال فرض می‌کند اطلاعات لازم برای ایجاد سفارش در $data وجود دارد و مدل Order برای ثبت آن تنظیم شده است.
نکته مهم این است که رویداد پس از پایان تراکنش منتشر می‌شود. این کار از اجرای Listener در زمانی که تراکنش هنوز تکمیل نشده جلوگیری می‌کند.
در برنامه واقعی، ممکن است ایجاد سفارش شامل اقلام سفارش، کاهش موجودی و ثبت پرداخت نیز باشد. همه عملیات لازم باید در مرز تراکنش مناسب مدیریت شوند.
مرحله چهارم: اتصال Event به Listener
Laravel در بسیاری از ساختارهای معمول، Listenerها را به‌صورت خودکار کشف می‌کند. اگر Listener به‌طور خودکار شناسایی نشد یا بخواهید اتصال را صریح تعریف کنید، می‌توانید از سازوکار ثبت Eventها در نسخه Laravel خود استفاده کنید.
برای مثال، در ساختارهایی که از EventServiceProvider استفاده می‌کنند، اتصال می‌تواند به شکل زیر باشد:
protected $listen = [
\App\Events\OrderPlaced::class => [
\App\Listeners\SendOrderConfirmation::class,
],
];
ساختار ثبت Eventها ممکن است با نسخه و پیکربندی پروژه تفاوت داشته باشد؛ بنابراین باید با ساختار واقعی پروژه هماهنگ شود.
اضافه کردن Listener دوم
حالا فرض کنید می‌خواهیم پس از ثبت سفارش، یک عملیات دیگر نیز اجرا شود؛ مثلاً ثبت یک رویداد در سیستم گزارش‌گیری.
می‌توانیم Listener جدیدی ایجاد کنیم و آن را به همان OrderPlaced متصل کنیم.
در این صورت، سرویس ثبت سفارش نیازی ندارد بداند چند Listener به این رویداد گوش می‌دهند.
این یکی از مزیت‌های مهم Observer است: می‌توانیم واکنش‌های جدیدی به یک رویداد اضافه کنیم، بدون آنکه منطق اصلی ثبت سفارش به همه آن‌ها وابسته شود.
چه زمانی از Observer استفاده کنیم؟
این الگو برای واکنش به اتفاقات مشخص در برنامه مفید است؛ مانند:
- ثبت سفارش
- پرداخت موفق
- تغییر وضعیت سفارش
- انتشار مقاله
- ثبت کاربر جدید
بااین‌حال، نباید هر عملیات ضروری کسب‌وکار را بدون بررسی به رویدادهای مستقل منتقل کنیم. اگر اجرای یک عملیات برای موفقیت عملیات اصلی ضروری است، باید شکست یا موفقیت آن به‌درستی مدیریت شود.
همچنین در Listenerهای صفی، بهتر است به رفتار پردازش مجدد، تراکنش‌های دیتابیس و احتمال اجرای دوباره عملیات توجه کنید.
تفاوت چهار الگوی Strategy، Factory، Adapter و Observer
جدول زیر کمک می‌کند هنگام طراحی یک قابلیت، الگوی مناسب را انتخاب کنید.
| الگو | مسئله‌ای که حل می‌کند | مثال در Laravel |
|---|---|---|
| Strategy | انتخاب بین روش‌های مختلف اجرای یک عملیات | روش‌های پرداخت |
| Factory | ساخت یا انتخاب نمونه مناسب | انتخاب درگاه پرداخت |
| Adapter | سازگار کردن رابط دو سیستم | یکپارچه‌سازی API پیامک |
| Observer | واکنش به رخدادهای برنامه | ارسال اعلان پس از ثبت سفارش |
ممکن است در یک بخش از پروژه چند الگو هم‌زمان به کار بروند. برای مثال، Strategy پیاده‌سازی‌های مختلف پرداخت را از هم جدا می‌کند، Factory درگاه انتخابی را می‌سازد و Observer به رویدادهای پس از پرداخت واکنش نشان می‌دهد.
مهم این است که هر الگو برای حل مسئله مشخصی استفاده شود، نه صرفاً برای اینکه معماری پروژه پیچیده‌تر به نظر برسد.
ارتباط Design Pattern با SOLID در Laravel
در مقاله اصول SOLID در Laravel یاد گرفتیم که طراحی خوب باید مسئولیت‌ها را مشخص کند، وابستگی‌ها را مدیریت کند و امکان توسعه را فراهم سازد.
الگوهای طراحی می‌توانند به پیاده‌سازی این اصول کمک کنند.
برای مثال:
- Strategy می‌تواند توسعه قابلیت‌های جدید را بدون تغییر منطق اصلی آسان‌تر کند.
- Factory می‌تواند مسئولیت ساخت اشیا را از کلاس مصرف‌کننده جدا کند.
- Adapter می‌تواند وابستگی مستقیم به یک سرویس خارجی را کاهش دهد.
- Observer می‌تواند بخش‌های مختلف برنامه را از یکدیگر مستقل‌تر کند.
بااین‌حال، استفاده از یک Design Pattern به‌تنهایی تضمین نمی‌کند که اصول SOLID رعایت شده‌اند. پیاده‌سازی نادرست هر الگو می‌تواند همچنان به کد پیچیده و وابسته منجر شود.
اشتباهات رایج در استفاده از Design Pattern
۱. استفاده از الگو بدون وجود مسئله واقعی
اگر یک کلاس ساده دارید که تنها یک وظیفه مشخص انجام می‌دهد، شاید نیازی به Factory، چند Interface و چند پیاده‌سازی نداشته باشید.
ابتدا مسئله را شناسایی کنید و سپس الگوی مناسب را انتخاب کنید.
۲. اشتباه گرفتن Strategy و Factory
Strategy رفتارهای مختلف را از یکدیگر جدا می‌کند؛ Factory ساخت یا انتخاب نمونه مناسب را مدیریت می‌کند. این دو می‌توانند با هم استفاده شوند، اما وظیفه یکسانی ندارند.
۳. استفاده بیش از حد از Observer
اگر تمام عملیات برنامه را به رویدادها منتقل کنیم، دنبال کردن مسیر اجرای برنامه دشوار می‌شود.
رویدادها را برای رخدادهای معنادار و واکنش‌های مستقل به کار ببرید و وابستگی‌های ضروری کسب‌وکار را به‌درستی مدیریت کنید.
۴. استفاده از Adapter بدون تعریف مرز مشخص
Adapter باید مسئول تبدیل رابط و سازگار کردن سیستم‌ها باشد. بهتر است منطق اصلی کسب‌وکار به جزئیات اختصاصی سرویس خارجی وابسته نشود.
۵. ساختن معماری بیش از نیاز پروژه
هدف از Design Pattern کاهش پیچیدگی در بلندمدت است. اگر یک الگو تعداد زیادی کلاس و وابستگی غیرضروری ایجاد کند، ممکن است انتخاب مناسبی برای آن مسئله نباشد.
چگونه Design Pattern مناسب را انتخاب کنیم؟
پیش از استفاده از یک الگو، به چند سؤال پاسخ دهید:
- دقیقاً چه مشکلی در طراحی فعلی وجود دارد؟
- آیا احتمال دارد رفتار یا پیاده‌سازی این بخش تغییر کند؟
- آیا چند روش متفاوت برای انجام یک کار داریم؟
- آیا باید از یک سرویس خارجی با رابط متفاوت استفاده کنیم؟
- آیا چند بخش مستقل باید به یک رخداد واکنش نشان دهند؟
- آیا استفاده از الگو واقعاً نگهداری و توسعه کد را آسان‌تر می‌کند؟
اگر پاسخ‌ها نشان دهند که مسئله مشخصی وجود دارد، انتخاب الگوی مناسب می‌تواند ارزشمند باشد. در غیر این صورت، بهتر است از پیچیده کردن ساختار خودداری کنید.
جمع‌بندی
Design Patternها ابزارهایی برای حل مسائل تکرارشونده در طراحی نرم‌افزار هستند. در Laravel می‌توان از آن‌ها برای ساخت معماری انعطاف‌پذیرتر، کاهش وابستگی‌ها و ساده‌تر کردن توسعه قابلیت‌های جدید استفاده کرد.
در این مقاله چهار الگوی کاربردی را بررسی کردیم:
- Strategy: برای جدا کردن روش‌های مختلف اجرای یک عملیات
- Factory: برای مدیریت ساخت یا انتخاب نمونه مناسب
- Adapter: برای سازگار کردن رابط سرویس‌های متفاوت
- Observer: برای واکنش به رویدادهای برنامه بدون وابسته کردن مستقیم بخش‌ها به یکدیگر
برای شروع، لازم نیست تمام پروژه را بر اساس مجموعه بزرگی از الگوها بازنویسی کنید. یک بخش واقعی از برنامه، مانند درگاه پرداخت یا ارسال اعلان، را انتخاب کنید و بررسی کنید آیا یکی از این الگوها می‌تواند مسئله موجود را ساده‌تر حل کند یا خیر.
معماری خوب زمانی شکل می‌گیرد که الگوی مناسب را برای مسئله مناسب انتخاب کنیم.
سوالات متداول
Design Pattern در Laravel چیست؟
Design Pattern یا الگوی طراحی، راه‌حلی شناخته‌شده برای یک مسئله تکرارشونده در طراحی نرم‌افزار است. در Laravel می‌توان از این الگوها برای مدیریت وابستگی‌ها، جداسازی مسئولیت‌ها و توسعه‌پذیرتر کردن برنامه استفاده کرد.
کدام Design Patternها در Laravel کاربرد بیشتری دارند؟
بسته به نوع پروژه، Strategy، Factory، Adapter، Observer، Decorator و Repository می‌توانند کاربردی باشند. هیچ الگویی برای تمام پروژه‌ها ضروری نیست و انتخاب آن باید بر اساس مسئله واقعی انجام شود.
تفاوت Design Pattern و SOLID چیست؟
SOLID مجموعه‌ای از اصول طراحی است که به ارزیابی ساختار کد کمک می‌کند. Design Patternها راه‌حل‌های شناخته‌شده‌ای برای مسائل خاص طراحی هستند. این دو مفهوم مکمل یکدیگرند.
آیا Laravel خودش از Design Pattern استفاده می‌کند؟
بله. برای نمونه، سیستم Event و Listener در Laravel کاربردی از الگوی Observer است. همچنین امکانات Service Container برای مدیریت وابستگی‌ها و ایجاد اشیا استفاده می‌شوند.
آیا برای استفاده از Design Pattern باید از Interface استفاده کنیم؟
خیر، همه الگوها الزاماً به Interface نیاز ندارند. اما در الگوهایی مانند Strategy، تعریف یک قرارداد مشترک می‌تواند جایگزینی پیاده‌سازی‌ها را آسان‌تر کند.
آیا Repository Pattern هم یک Design Pattern است؟
بله، Repository یک الگوی طراحی برای جدا کردن نحوه دسترسی به داده‌ها از کد مصرف‌کننده است. بااین‌حال، استفاده از آن در تمام پروژه‌های Laravel ضروری نیست و باید با توجه به پیچیدگی و نیازهای پروژه تصمیم گرفت.
