مبادئ SOLID في PHP: النظرية والتطبيق من الألف إلى الياء

مقدمة: لماذا تعتبر مبادئ SOLID أساس كود PHP عالي الجودة

كل مطور PHP يواجه عاجلاً أم آجلاً موقفاً يتحول فيه المشروع الصغير إلى "كود سباغيتي". تصبح الفئات مثقلة، والتغييرات في جزء من النظام تكسر أجزاء أخرى، ويصبح الاختبار كابوساً. لحل هذه المشكلات، صاغ روبرت مارتن (العم بوب) المبادئ الخمسة لـ SOLID. هذه المبادئ ليست نظرية مجردة، بل أدوات عملية تساعد في إنشاء كود PHP مرن وقابل للصيانة والاختبار.

في هذه المقالة، سنشرح كل مبدأ من مبادئ SOLID: من النظرية إلى أمثلة حقيقية على PHP 8.x. ستتعلم كيفية تطبيقها في التطوير اليومي وما هي الأنماط المضادة التي يجب تجنبها.

1. مبدأ المسؤولية الواحدة (SRP)

النظرية

ينص المبدأ على: يجب أن يكون للفئة سبب واحد فقط للتغيير. وهذا يعني أن كل فئة يجب أن تكون مسؤولة عن وظيفة واحدة محددة أو منطق عمل معين.

النمط المضاد (انتهاك SRP)

<?phpclass OrderProcessor {    public function process(Order $order): void {        // 1. التحقق من صحة الطلب        if (empty($order->getItems())) {            throw new \\InvalidArgumentException('Order has no items');        }                // 2. الحفظ في قاعدة البيانات        $db = new \\PDO('mysql:host=localhost;dbname=shop', 'user', 'pass');        $stmt = $db->prepare('INSERT INTO orders ...');        $stmt->execute([...]);                // 3. إرسال البريد الإلكتروني        mail($order->getCustomerEmail(), 'تم تأكيد الطلب', '...');                // 4. التسجيل        file_put_contents('/var/log/orders.log', 'تم معالجة الطلب: '.$order->getId());    }}?>

هنا، فئة OrderProcessor تقوم بالكثير: التحقق، العمل مع قاعدة البيانات، إرسال البريد الإلكتروني، التسجيل. انتهاك SRP يؤدي إلى أن تغيير منطق إرسال البريد الإلكتروني سيتطلب تغيير الفئة المسؤولة عن معالجة الطلبات.

إعادة الهيكلة مع الالتزام بـ SRP

<?phpclass OrderValidator {    public function validate(Order $order): void {        if (empty($order->getItems())) {            throw new \\InvalidArgumentException('Order has no items');        }    }}

class OrderRepository {    public function save(Order $order): void {        // منطق الحفظ في قاعدة البيانات    }}

class EmailNotifier {    public function sendOrderConfirmation(Order $order): void {        // منطق إرسال البريد الإلكتروني    }}

class Logger {    public function log(string $message): void {        // التسجيل    }}

class OrderProcessor {    public function __construct(        private OrderValidator $validator,        private OrderRepository $repository,        private EmailNotifier $notifier,        private Logger $logger    ) {}        public function process(Order $order): void {        $this->validator->validate($order);        $this->repository->save($order);        $this->notifier->sendOrderConfirmation($order);        $this->logger->log('تم معالجة الطلب: '.$order->getId());    }}?>

الآن كل فئة لها مسؤولية واحدة. تغيير منطق البريد الإلكتروني لا يؤثر على العمل مع قاعدة البيانات.

2. مبدأ الفتح/الإغلاق (OCP)

النظرية

يجب أن تكون الكيانات البرمجية مفتوحة للتمديد ولكن مغلقة للتعديل. بمعنى آخر، يجب أن تكون قادراً على إضافة وظائف جديدة دون تغيير الكود الموجود.

النمط المضاد

<?phpclass PaymentProcessor {    public function process(string $type, float $amount): void {        if ($type === 'credit_card') {            // معالجة بطاقة الائتمان        } elseif ($type === 'paypal') {            // معالجة PayPal\