TypeScript में SOLID सिद्धांत: सिद्धांत और उदाहरणों के साथ व्यवहार

परिचय: TypeScript में SOLID क्यों महत्वपूर्ण है

SOLID, रॉबर्ट मार्टिन (अंकल बॉब) द्वारा प्रतिपादित ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के पाँच मूलभूत सिद्धांतों का एक संक्षिप्त नाम (एक्रोनिम) है। TypeScript के संदर्भ में, ये सिद्धांत अपनी सख्त टाइप सिस्टम और आधुनिक OOP प्रतिमानों के समर्थन के कारण विशेष मूल्य रखते हैं। SOLID का अनुप्रयोग कोड को अधिक लचीला, परीक्षण योग्य और रखरखाव योग्य बनाता है, जो स्केलेबल प्रोजेक्ट्स के लिए महत्वपूर्ण है।

इस लेख में, हम व्यावहारिक TypeScript उदाहरणों के साथ SOLID के प्रत्येक सिद्धांत का विश्लेषण करेंगे, एंटी-पैटर्न और उनके सही कार्यान्वयन दिखाएंगे। आप सीखेंगे कि ऐसा कोड कैसे लिखें जो नई कार्यक्षमता जोड़ने पर टूटे नहीं।

1. Single Responsibility Principle (SRP) — एकल उत्तरदायित्व का सिद्धांत

सिद्धांत

प्रत्येक क्लास में बदलाव का केवल एक ही कारण होना चाहिए। इसका मतलब है कि क्लास को प्रोग्राम की कार्यक्षमता के केवल एक हिस्से के लिए जिम्मेदार होना चाहिए। यदि कोई क्लास कई कार्य करता है, तो उसे बनाए रखना और परीक्षण करना कठिन हो जाता है।

एंटी-पैटर्न (SRP का उल्लंघन)

class UserService {    saveUser(user: User): void {        // डेटाबेस में सेव करना        console.log('User saved');    }

    sendEmail(user: User, message: string): void {        // ईमेल भेजना        console.log(`Email sent to ${user.email}`);    }

    generateReport(user: User): string {        // रिपोर्ट जनरेट करना        return `Report for ${user.name}`;    }}

सही कार्यान्वयन (SRP)

class UserRepository {    save(user: User): void {        // केवल सेव करना    }}

class EmailService {    send(user: User, message: string): void {        // केवल ईमेल भेजना    }}

class ReportGenerator {    generate(user: User): string {        // केवल रिपोर्ट जनरेट करना    }}

2. Open-Closed Principle (OCP) — खुले/बंद का सिद्धांत

सिद्धांत

क्लास विस्तार के लिए खुले होने चाहिए, लेकिन संशोधन के लिए बंद होने चाहिए। नई कार्यक्षमता को मौजूदा कोड को बदलने के बजाय इनहेरिटेंस या कम्पोज़ीशन के माध्यम से जोड़ा जाना चाहिए।

एंटी-पैटर्न (OCP का उल्लंघन)

class PaymentProcessor {    processPayment(type: string, amount: number): void {        if (type === 'card') {            // कार्ड प्रोसेसिंग        } else if (type === 'paypal') {            // PayPal प्रोसेसिंग        } else if (type === 'crypto') {            // क्रिप्टोकरेंसी प्रोसेसिंग        }        // नया टाइप जोड़ने पर — क्लास बदलना होगा!    }}

सही कार्यान्वयन (OCP)

interface PaymentMethod {    process(amount: number): void;}

class CardPayment implements PaymentMethod {    process(amount: number): void {        console.log(`Processing card payment: $${amount}`);    }}

class PayPalPayment implements PaymentMethod {    process(amount: number): void {        console.log(`Processing PayPal payment: $${amount}`);    }}

class PaymentProcessor {    constructor(private paymentMethod: PaymentMethod) {}

    process(amount: number): void {        this.paymentMethod.process(amount);    }}

3. Liskov Substitution Principle (LSP) — लिस्कोव प्रतिस्थापन का सिद्धांत

सिद्धांत

बेस क्लास की वस्तुओं को उनके उपवर्गों की वस्तुओं द्वारा प्रोग्राम के कामकाज को बाधित किए बिना प्रतिस्थापित किया जाना चाहिए। उपवर्गों को बेस क्लास के अपेक्षित व्यवहार को नहीं बदलना चाहिए।

एंटी-पैटर्न (LSP का उल्लंघन)

class Rectangle {    constructor(public width: number, public height: number) {}

    setWidth(width: number): void {        this.width = width;    }

    setHeight(height: number): void {        this.height = height;    }

    getArea(): number {        return this.width * this.height;    }}

class Square extends Rectangle {```