ما هي الواجهات (Facades) في Laravel؟

Question

Accepted Answer

**الواجهات (Facades)** توفر واجهة نظيفة تشبه الطرق الثابتة (static-like) للفئات في حاوية الخدمات — مثل `Cache::get()`، `DB::table()`، `Route::get()`. تبدو وكأنها استدعاءات طرق ثابتة لكنها في الواقع **تحول الاستدعاء إلى كائنات حقيقية يتم حلها من الحاوية**، مما يجمع بين سهولة بناء الجملة الثابتة وقابلية الاختبار من حقن التبعيات.

## الواجهات تبدو ثابتة لكنها ليست كذلك

```php
use Illuminate\Support\Facades\Cache;

Cache::put('key', 'value', 60);     // looks like a static call...
Cache::get('key');

// ...but under the hood it proxies to a container-resolved cache instance.
// Equivalent to: app('cache')->put('key', 'value', 60);
```

الواجهة ليست فئة ثابتة حقيقية — فهي تحول الاستدعاء إلى كائن فعلي يتم حله من حاوية الخدمات. وبالتالي تحصل على بناء جملة نظيف وملائم بينما يتم القيام بالعمل الفعلي بواسطة خدمة قابلة للحقن والمحاكاة.

## الواجهات الشائعة

```php
DB::table('users')->get();           // database
Cache::remember('stats', 60, fn() => compute());   // caching
Auth::user();                         // authentication
Route::get('/', ...);                 // routing
Log::info('message');                 // logging
Storage::put('file.txt', $content);   // filesystem
Mail::to($user)->send(new Welcome()); // mail
Validator::make($data, $rules);       // validation
```

توفر الواجهات واجهة برمجية سهلة التذكر وتعبيرية لخدمات Laravel — جزء من "بناء الجملة الأنيق" للإطار.

## الواجهات قابلة للاختبار (على عكس الثوابت الحقيقية)

```php
// you can MOCK a facade in tests (impossible with true static methods)
Cache::shouldReceive('get')->with('key')->andReturn('value');
Mail::fake();                          // assert mail was sent without sending it
Mail::assertSent(WelcomeEmail::class);
```

لأن الواجهات تحول إلى كائنات الحاوية، يمكن لـ Laravel استبدالها بمحاكات للاختبار — `Cache::shouldReceive(...)`، `Mail::fake()` — شيء لا تسمح به الطرق الثابتة الحقيقية.

## الواجهات مقابل حقن التبعيات

```text
Facade → convenient static-like syntax (Cache::get()), great for quick access
DI (constructor injection) → explicit dependencies, clearer for testing/coupling
→ Both resolve from the container; facades are sugar. Use DI when you want explicit
  dependencies; facades for concise access. (Some prefer DI for clarity.)
```

## لماذا يهم هذا

الواجهات هي ميزة مميزة وشاملة في Laravel — تظهر في جميع أنحاء كود Laravel (`DB::`، `Cache::`، `Auth::`، `Route::`، إلخ)، لذا فهم كيفية عملها مهم لقراءة وكتابة تطبيقات Laravel.

الرؤية الأساسية هي أن الواجهات **تبدو وكأنها استدعاءات ثابتة لكنها تحول في الواقع إلى كائنات يتم حلها من حاوية الخدمات** — هذا يعطيك بناء جملة مناسب وتعبيري يشبه الطرق الثابتة وهو جزء من جاذبية Laravel، بينما يحافظ على فوائد حقن التبعيات تحتها (العمل الفعلي يتم بواسطة خدمات قابلة للحقن والمحاكاة).
ack بشكل حاسم، هذا يعني أن الواجهات **قابلة للاختبار** رغم مظهرها الثابت: يمكن لـ Laravel استبدال المحاكات (`Cache::shouldReceive()`، `Mail::fake()`) — شيء مستحيل مع الطرق الثابتة الحقيقية، والتي يصعب اختبارها بشكل كبير.

فهم كيفية عمل الواجهات (حل الحاوية)، والواجهات الشائعة، وقابليتها للاختبار، والمقابلة **بين الحقن الصريح للتبعيات** (الواجهات للوصول المختصر مقابل حقن المُنشئ للتبعيات الواضحة والصريحة — كلاهما صالح، يتم الحل من نفس الحاوية) هو معرفة مهمة للعمل بفعالية مع Laravel وللقيام باختيارات معمارية مستنيرة.

بما أن الواجهات هي واحدة من أكثر الميزات المميزة في Laravel وتُستخدم باستمرار، فإن توضيح غموضها (فهي ليست ثوابت سحرية بل وسطاء الحاوية) ومعرفة متى تستخدمها مقابل حقن التبعيات يعكس فهماً قوياً لتصميم الإطار ويساعدك على كتابة كود Laravel نظيف وقابل للاختبار.