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

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

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

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

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

सिद्धांत: प्रत्येक वर्ग या मॉड्यूल में बदलाव का केवल एक ही कारण होना चाहिए। दूसरे शब्दों में, वर्ग को प्रोग्राम की केवल एक कार्यक्षमता के लिए जिम्मेदार होना चाहिए।

सिद्धांत का उल्लंघन:

// ❌ खराब: वर्ग डेटा, सहेजने और फ़ॉर्मेटिंग सभी के लिए जिम्मेदार हैclass User {  constructor(public name: string, public email: string) {}

  saveToDatabase(): void {    console.log(`${this.name} को DB में सहेजा जा रहा है`);  }

  generateHTML(): string {    return `<div>${this.name} - ${this.email}</div>`;  }}

SRP लागू करके सुधार:

// ✅ अच्छा: जिम्मेदारी को तीन वर्गों में विभाजित करेंclass User {  constructor(public name: string, public email: string) {}}

class UserRepository {  save(user: User): void {    console.log(`${user.name} को DB में सहेजा जा रहा है`);  }}

class UserView {  render(user: User): string {    return `<div>${user.name} - ${user.email}</div>`;  }}

अब प्रत्येक वर्ग की एक स्पष्ट जिम्मेदारी है, जो कोड के परीक्षण और संशोधन को सरल बनाता है।

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

सिद्धांत: सॉफ़्टवेयर संस्थाएँ (वर्ग, मॉड्यूल, फ़ंक्शन) विस्तार के लिए खुली होनी चाहिए, लेकिन संशोधन के लिए बंद होनी चाहिए। इसका मतलब है कि आपको मौजूदा कोड को बदले बिना नई कार्यक्षमता जोड़ने में सक्षम होना चाहिए।

सिद्धांत का उल्लंघन:

// ❌ खराब: नए आकार का प्रकार जोड़ने पर AreaCalculator वर्ग को बदलना होगाclass AreaCalculator {  calculate(shape: any): number {    if (shape.type === 'circle') {      return Math.PI * shape.radius ** 2;    } else if (shape.type === 'rectangle') {      return shape.width * shape.height;    }    return 0;  }}

OCP लागू करके सुधार:

// ✅ अच्छा: इंटरफ़ेस और पॉलीमॉर्फिज़्म का उपयोग करेंinterface Shape {  area(): number;}

class Circle implements Shape {  constructor(public radius: number) {}  area(): number {    return Math.PI * this.radius ** 2;  }}

class Rectangle implements Shape {  constructor(public width: number, public height: number) {}  area(): number {    return this.width * this.height;  }}

class AreaCalculator {  calculate(shape: Shape): number {    return shape.area(); // संशोधन के लिए बंद, विस्तार के लिए खुला  }}

अब एक नया आकार (जैसे, Triangle) जोड़ने के लिए, बस Shape इंटरफ़ेस को लागू करने वाला एक नया वर्ग बनाना होगा — AreaCalculator को बदलने की आवश्यकता नहीं है।

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

सिद्धांत: प्रोग्राम में ऑब्जेक्ट को उनके उपप्रकारों के उदाहरणों द्वारा प्रतिस्थापित किया जाना चाहिए, बिना प्रोग्राम की शुद्धता का उल्लंघन किए। यदि आपके पास एक आधार वर्ग और एक उत्तराधिकारी है, तो आधार वर्ग के साथ काम करने वाला कोड उत्तराधिकारी के साथ भी सही ढंग से काम करना चाहिए।

सिद्धांत का उल्लंघन:

// ❌ खराब