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

S - एकल उत्तरदायित्व सिद्धांत (SRP)

वाहन उदाहरण: कल्पना कीजिए कि आपके पास एक कार है। यह ड्राइविंग के लिए ज़िम्मेदार है, लेकिन इसे अपने स्वयं के रखरखाव (जैसे तेल परिवर्तन या टायर रोटेशन) को संभालने के लिए जिम्मेदार नहीं होना चाहिए। इसके बजाय, उसके लिए एक अलग मैकेनिक जिम्मेदार है।
स्पष्टीकरण: हमारे कोड में, वाहन वर्ग को केवल वाहन से संबंधित चीजों को ही संभालना चाहिए, जैसे उसके मेक और मॉडल को संग्रहीत करना। यदि हमें रखरखाव का प्रबंधन करने की आवश्यकता है, तो हम उसके लिए एक अलग रखरखाव वर्ग बनाते हैं। इस तरह, प्रत्येक वर्ग के पास एक कार्य या जिम्मेदारी होती है, जिससे कोड को प्रबंधित करना आसान हो जाता है।

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end
end

class Maintenance
  def initialize(vehicle)
    @vehicle = vehicle
  end

  def perform_maintenance
    puts "Performing maintenance on #{@vehicle.make} #{@vehicle.model}"
  end
end

O - खुला/बंद सिद्धांत (OCP)

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

class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def description
    "#{@make} #{@model}"
  end
end

class ElectricVehicle 





  
  
  L - Liskov प्रतिस्थापन सिद्धांत (LSP)


वाहन उदाहरण: कल्पना करें कि आपके पास वाहनों का एक बेड़ा है, और आप बिना किसी समस्या के किसी भी नियमित कार को इलेक्ट्रिक कार से बदल सकते हैं। दोनों को सिस्टम को तोड़े बिना अपना मूल कार्य - ड्राइविंग - करने में सक्षम होना चाहिए।
स्पष्टीकरण: किसी भी उपवर्ग (जैसे इलेक्ट्रिकवाहन) को प्रोग्राम के व्यवहार में बदलाव किए बिना अपने मूल वर्ग (वाहन) को बदलने में सक्षम होना चाहिए। यह सुनिश्चित करता है कि हमारा कोड विभिन्न प्रकार के वाहनों को एक ही तरह से संभाल सकता है।


class Vehicle
  def initialize(make, model)
    @make = make
    @model = model
  end

  def drive
    puts "Driving the #{@make} #{@model}"
  end
end

class ElectricVehicle 





  
  
  I - इंटरफ़ेस पृथक्करण सिद्धांत (ISP)


वाहन उदाहरण: कल्पना कीजिए कि आपके पास विभिन्न प्रकार के वाहन हैं: कुछ को चार्ज किया जा सकता है (जैसे इलेक्ट्रिक कार), और कुछ को केवल चलाया जा सकता है (जैसे गैस कार)। आप नहीं चाहेंगे कि गैस कार को चार्जिंग-संबंधी तरीकों से जूझना पड़े।
स्पष्टीकरण: कक्षाओं को केवल उन्हीं इंटरफेस (या व्यवहार) को लागू करना चाहिए जिनकी उन्हें आवश्यकता है। उदाहरण के लिए, एक इलेक्ट्रिक वाहन ड्राइव करने योग्य और चार्ज करने योग्य दोनों इंटरफेस लागू कर सकता है, जबकि एक नियमित वाहन केवल ड्राइव करने योग्य लागू करता है।


module Drivable
  def drive
    raise NotImplementedError, "This #{self.class} cannot drive"
  end
end

module Chargeable
  def charge
    raise NotImplementedError, "This #{self.class} cannot be charged"
  end
end

class Vehicle
  include Drivable

  def initialize(make, model)
    @make = make
    @model = model
  end

  def drive
    puts "Driving the #{@make} #{@model}"
  end
end

class ElectricVehicle 





  
  
  D - निर्भरता व्युत्क्रम सिद्धांत (DIP)


वाहन उदाहरण: कल्पना करें कि एक कार में विभिन्न प्रकार के इंजन हो सकते हैं: एक गैस इंजन या एक इलेक्ट्रिक इंजन। किसी विशिष्ट इंजन प्रकार पर सीधे निर्भर होने के बजाय, कार को अधिक सामान्य इंजन इंटरफ़ेस पर निर्भर होना चाहिए ताकि वह किसी भी प्रकार के इंजन का उपयोग कर सके।
स्पष्टीकरण: उच्च-स्तरीय मॉड्यूल (जैसे वाहन) को निम्न-स्तरीय मॉड्यूल (जैसे गैसइंजन या इलेक्ट्रिकइंजन) पर निर्भर नहीं होना चाहिए। दोनों को अमूर्त (एक इंजन इंटरफ़ेस की तरह) पर निर्भर होना चाहिए। यह सिस्टम को अधिक लचीला और बदलने में आसान बनाता है।


class Engine
  def start
    raise NotImplementedError, "This #{self.class} cannot start"
  end
end

class GasEngine 



इस वाहन उदाहरण में SOLID सिद्धांतों का पालन करके, हम एक ऐसी प्रणाली बना सकते हैं जिसे बनाए रखना, विस्तार करना और नई आवश्यकताओं के अनुकूल बनाना आसान है।

लिंक्डइन: https://www.linkedin.com/in/nandsoni11/