परिचय: SOLID सिर्फ एक हठधर्मिता नहीं, बल्कि एक उपकरण क्यों है
\nअधिकांश डेवलपर्स जानते हैं कि SOLID ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग के पांच सिद्धांत हैं: Single Responsibility, Open-Closed, Liskov Substitution, Interface Segregation और Dependency Inversion। हालांकि, व्यवहार में समझ अक्सर नियमों का यांत्रिक पालन करने तक सीमित हो जाती है। इस लेख में हम आगे बढ़ेंगे: हम PHP में SOLID के उन्नत उपयोग परिदृश्यों का विश्लेषण करेंगे, उन एंटीपैटर्न पर विचार करेंगे जो सिद्धांतों का उल्लंघन करते हैं, और दिखाएंगे कि कैसे SOLID को ध्यान में रखते हुए रिफैक्टरिंग कोड को लचीला और परीक्षण योग्य बनाती है।
\nयह सामग्री Middle+ और Senior स्तर के डेवलपर्स के लिए है जो पहले से ही PHP में कोड लिख रहे हैं और अपने प्रोजेक्ट्स की आर्किटेक्चर में सुधार करना चाहते हैं।
\n\n1. एकल उत्तरदायित्व का सिद्धांत (SRP): जब क्लास "बहुत अधिक जानता है"
\nशास्त्रीय सूत्रीकरण: "एक क्लास में बदलाव का केवल एक ही कारण होना चाहिए"। उन्नत स्तर पर यह समझना महत्वपूर्ण है कि "बदलाव का कारण" एक व्यावसायिक आवश्यकता है। यदि आपकी क्लास सत्यापन नियमों, आउटपुट प्रारूप और सेव लॉजिक में बदलाव के कारण बदलती है - तो यह SRP का उल्लंघन है।
\n\nउल्लंघन का उदाहरण (God Object)
\nclass OrderProcessor {\n public function process(array $data): void {\n // 1. डेटा सत्यापन\n if (empty($data['user_id']) || empty($data['items'])) {\n throw new InvalidArgumentException('Invalid order data');\n }\n \n // 2. लागत की गणना\n $total = 0;\n foreach ($data['items'] as $item) {\n $total += $item['price'] * $item['quantity'];\n }\n \n // 3. डेटाबेस में सेव करना\n $sql = "INSERT INTO orders (user_id, total, status) VALUES (?, ?, 'pending')";\n // ... क्वेरी निष्पादन\n \n // 4. ईमेल भेजना\n mail($data['user_email'], 'Order confirmation', "Total: $total");\n }\n}\n\nSRP के साथ रिफैक्टरिंग
\nस्पष्ट उत्तरदायित्व क्षेत्रों वाली तीन क्लासों में विभाजित करें:
\nclass OrderValidator {\n public function validate(array $data): void {\n if (empty($data['user_id']) || empty($data['items'])) {\n throw new InvalidArgumentException('Invalid order data');\n }\n }\n}\n\nclass OrderCalculator {\n public function calculateTotal(array $items): float {\n return array_reduce($items, function ($carry, $item) {\n return $carry + $item['price'] * $item['quantity'];\n }, 0.0);\n }\n}\n\nclass OrderRepository {\n public function save(int $userId, float $total, string $status = 'pending'): int {\n // डेटाबेस में सेव करने की लॉजिक\n return 42; // ऑर्डर ID\n }\n}\n\nclass OrderProcessor {\n public function __construct(\n private OrderValidator $validator,\n private OrderCalculator $calculator,\n private OrderRepository $repository,\n private Mailer $mailer\n ) {}\n \n public function process(array $data): void {\n $this->validator->validate($data);\n $total = $this->calculator->calculateTotal($data['items']);\n $orderId = $this->repository->save($data['user_id'], $total);\n $this->mailer->send($data['user_email'], 'Order #' . $orderId);\n }\n}\n\n2. खुले/बंद का सिद्धांत (OCP): संशोधन के बिना विस्तार
\nOCP का सार: क्लासेस विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद। व्यवहार में इसका अर्थ है सशर्त निर्माणों के बजाय पॉलीमॉर्फिज्म और एब्स्ट्रैक्शन का उपयोग।
\n\nOCP का उल्लंघन: प्रत्येक नए प्रकार के लिए switch-case
\nclass PaymentProcessor {\n public function pay(string $type, float $amount): void {\n switch ($type) {\n case 'credit_card':\n // कार्ड प्रोसेसिंग\n break;\n case 'paypal':\n // PayPal प्रोसेसिंग\n break;\n // नया प्रकार जोड़ने पर — क्लास बदलें!\n }\n }\n