SOLID का उपयोग करके एक लचीले कोड लिखना

अनुवादक से: सेवेरिन पेर्स ने आपके लिए प्रोग्रामिंग में एसओएलआईडी सिद्धांतों के उपयोग पर एक लेख प्रकाशित किया। लेख की जानकारी अनुभव के साथ शुरुआती और प्रोग्रामर दोनों के लिए उपयोगी होगी।

यदि आप एक डेवलपर हैं, तो आपने शायद SOLID सिद्धांतों के बारे में सुना होगा। वे प्रोग्रामर को स्वच्छ, अच्छी तरह से संरचित और आसानी से बनाए रखने वाले कोड लिखने में सक्षम बनाते हैं। यह ध्यान देने योग्य है कि प्रोग्रामिंग में इस या उस कार्य को ठीक से कैसे करें, इसके लिए कई दृष्टिकोण हैं। विभिन्न विशेषज्ञों के अलग-अलग विचार और समझ "सही तरीका" है, यह सब प्रत्येक व्यक्ति के अनुभव पर निर्भर करता है। फिर भी, SOLID में घोषित विचारों को आईटी समुदाय के लगभग सभी प्रतिनिधियों द्वारा स्वीकार किया जाता है। वे कई अच्छे विकास प्रबंधन प्रथाओं के उद्भव और विकास के लिए शुरुआती बिंदु बन गए।

आइए देखें कि ठोस सिद्धांत क्या हैं और वे हमारी मदद कैसे करते हैं।

स्किलबॉक्स अनुशंसा करता है: व्यावहारिक पाठ्यक्रम "मोबाइल डेवलपर प्रो" ।

हम आपको याद दिलाते हैं: "हैबर" के सभी पाठकों के लिए - "हैबर" प्रोमो कोड का उपयोग करके किसी भी स्किलबॉक्स कोर्स के लिए पंजीकरण करते समय 10,000 रूबल की छूट।

SOLID क्या है?

यह शब्द एक संक्षिप्त नाम है, शब्द का प्रत्येक अक्षर एक निश्चित सिद्धांत के नाम की शुरुआत है:

• एस इंगलिश रिस्पांसिबिलिटी प्रिंसिपल। एक मॉड्यूल में परिवर्तन का एक और केवल एक कारण हो सकता है।
• हे कलम / बंद सिद्धांत । कक्षाओं और अन्य तत्वों को विस्तार के लिए खुला होना चाहिए, लेकिन संशोधन के लिए बंद।
• एल iskov प्रतिस्थापन सिद्धांत है । आधार प्रकार का उपयोग करने वाले कार्य यह जानने के बिना आधार प्रकार के उपप्रकार का उपयोग करने में सक्षम होना चाहिए।
• I nterface पृथक्करण सिद्धांत । सॉफ्टवेयर संस्थाओं को उन तरीकों पर निर्भर नहीं होना चाहिए जिनका वे उपयोग नहीं करते हैं।
• डी एपेंडेंसी उलटा सिद्धांत । ऊपरी स्तर के मॉड्यूल को निचले स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए।

एकमात्र जिम्मेदारी का सिद्धांत

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

इस अवधारणा में डेविड परनासस द्वारा तैयार कई अवधारणाएँ भी शामिल थीं। दो मुख्य हैं एनकैप्सुलेशन और जानकारी छिपाना। पर्नासस ने तर्क दिया कि एक प्रणाली को अलग-अलग मॉड्यूल में विभाजित करना फ्लोचार्ट या निष्पादन प्रवाह के विश्लेषण पर आधारित नहीं होना चाहिए। किसी भी मॉड्यूल में एक विशिष्ट समाधान होना चाहिए जो ग्राहकों को न्यूनतम जानकारी प्रदान करता है।

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

दिव्य वस्तु

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

उदाहरण देखें और निम्नलिखित को निर्धारित करने का प्रयास करें:
उन वस्तुओं की जिम्मेदारियां जो अंतरिक्ष यान वर्ग में घोषित की जाती हैं।
जिन्हें स्पेस स्टेशन के काम में दिलचस्पी हो सकती है।

class SpaceStation def initialize @supplies = {} @fuel = 0 end def run_sensors puts "----- Sensor Action -----" puts "Running sensors!" end def load_supplies(type, quantity) puts "----- Supply Action -----" puts "Loading #{quantity} units of #{type} in the supply hold." if @supplies[type] @supplies[type] += quantity else @supplies[type] = quantity end end def use_supplies(type, quantity) puts "----- Supply Action -----" if @supplies[type] != nil && @supplies[type] > quantity puts "Using #{quantity} of #{type} from the supply hold." @supplies[type] -= quantity else puts "Supply Error: Insufficient #{type} in the supply hold." end end def report_supplies puts "----- Supply Report -----" if @supplies.keys.length > 0 @supplies.each do |type, quantity| puts "#{type} avalilable: #{quantity} units" end else puts "Supply hold is empty." end end def load_fuel(quantity) puts "----- Fuel Action -----" puts "Loading #{quantity} units of fuel in the tank." @fuel += quantity end def report_fuel puts "----- Fuel Report -----" puts "#{@fuel} units of fuel available." end def activate_thrusters puts "----- Thruster Action -----" if @fuel >= 10 puts "Thrusting action successful." @fuel -= 10 else puts "Thruster Error: Insufficient fuel available." end end end 

दरअसल, हमारा स्पेस स्टेशन नॉन-फंक्शनल है (मुझे लगता है कि मुझे निकट भविष्य में नासा से कॉल नहीं मिलेगा), लेकिन विश्लेषण करने के लिए कुछ है।

तो, अंतरिक्ष यान वर्ग में कई अलग-अलग जिम्मेदारियां (या कार्य) हैं। उन सभी को प्रकारों में विभाजित किया जा सकता है:

• सेंसर;
• आपूर्ति (उपभोग्य);
• ईंधन;
• बूस्टर।

इस तथ्य के बावजूद कि स्टेशन में कोई भी स्टेशन कर्मचारी परिभाषित नहीं है, हम आसानी से कल्पना कर सकते हैं कि कौन जिम्मेदार है। सबसे अधिक संभावना है, वैज्ञानिक सेंसर को नियंत्रित करता है, तर्कशास्त्री संसाधनों की आपूर्ति के लिए जिम्मेदार है, इंजीनियर ईंधन की आपूर्ति के लिए जिम्मेदार है, और पायलट त्वरक को नियंत्रित करता है।

क्या हम कह सकते हैं कि यह कार्यक्रम एसआरपी अनुरूप नहीं है? हां बिल्कुल। लेकिन अंतरिक्ष यान वर्ग एक विशिष्ट "दिव्य वस्तु" है जो सब कुछ जानता है और सब कुछ करता है। यह ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग में मुख्य विरोधी पैटर्न है। एक शुरुआत के लिए, ऐसी वस्तुओं को बनाए रखना बेहद मुश्किल है। अब तक, कार्यक्रम बहुत सरल है, हाँ, लेकिन कल्पना करें कि यदि हम नई सुविधाओं को जोड़ते हैं तो क्या होगा। शायद हमारे अंतरिक्ष स्टेशन को एक चिकित्सा केंद्र या बैठक कक्ष की आवश्यकता होगी। और जितनी अधिक सुविधाएँ हैं, उतने ही अधिक अंतरिक्ष यान विकसित होंगे। खैर, चूंकि यह ऑब्जेक्ट दूसरों के साथ जुड़ा होगा, पूरे परिसर का रखरखाव और भी जटिल हो जाएगा। नतीजतन, हम, उदाहरण के लिए, त्वरक के काम को बाधित कर सकते हैं। यदि कोई शोधकर्ता सेंसर के साथ काम करने में बदलाव के लिए कहता है, तो यह स्टेशन की संचार प्रणालियों को अच्छी तरह से प्रभावित कर सकता है।

एसआरपी सिद्धांत का उल्लंघन एक अल्पकालिक सामरिक जीत दे सकता है, लेकिन अंत में हम "युद्ध हार जाएंगे", भविष्य में ऐसे राक्षस की सेवा करना बहुत मुश्किल होगा। कार्यक्रम को कोड के अलग-अलग वर्गों में विभाजित करना सबसे अच्छा है, जिनमें से प्रत्येक एक विशिष्ट ऑपरेशन करने के लिए जिम्मेदार है। इसे ध्यान में रखते हुए, 'SpaceStation क्लास' बदलें।

जिम्मेदारी साझा करें

ऊपर, हमने चार प्रकार के ऑपरेशनों की पहचान की जो अंतरिक्ष यान वर्ग द्वारा नियंत्रित होते हैं। जब refactoring, हम उन्हें ध्यान में रखेंगे। अपडेटेड कोड SRP से बेहतर मेल खाते हैं।

 class SpaceStation attr_reader :sensors, :supply_hold, :fuel_tank, :thrusters def initialize @supply_hold = SupplyHold.new @sensors = Sensors.new @fuel_tank = FuelTank.new @thrusters = Thrusters.new(@fuel_tank) end end class Sensors def run_sensors puts "----- Sensor Action -----" puts "Running sensors!" end end class SupplyHold attr_accessor :supplies def initialize @supplies = {} end def load_supplies(type, quantity) puts "----- Supply Action -----" puts "Loading #{quantity} units of #{type} in the supply hold." if @supplies[type] @supplies[type] += quantity else @supplies[type] = quantity end end def use_supplies(type, quantity) puts "----- Supply Action -----" if @supplies[type] != nil && @supplies[type] > quantity puts "Using #{quantity} of #{type} from the supply hold." @supplies[type] -= quantity else puts "Supply Error: Insufficient #{type} in the supply hold." end end def report_supplies puts "----- Supply Report -----" if @supplies.keys.length > 0 @supplies.each do |type, quantity| puts "#{type} avalilable: #{quantity} units" end else puts "Supply hold is empty." end end end class FuelTank attr_accessor :fuel def initialize @fuel = 0 end def get_fuel_levels @fuel end def load_fuel(quantity) puts "----- Fuel Action -----" puts "Loading #{quantity} units of fuel in the tank." @fuel += quantity end def use_fuel(quantity) puts "----- Fuel Action -----" puts "Using #{quantity} units of fuel from the tank." @fuel -= quantity end def report_fuel puts "----- Fuel Report -----" puts "#{@fuel} units of fuel available." end end class Thrusters def initialize(fuel_tank) @linked_fuel_tank = fuel_tank end def activate_thrusters puts "----- Thruster Action -----" if @linked_fuel_tank.get_fuel_levels >= 10 puts "Thrusting action successful." @linked_fuel_tank.use_fuel(10) else puts "Thruster Error: Insufficient fuel available." end end end 

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

किसी भी चर के लिए अब एक संबंधित वर्ग है: सेंसर; SupplyHold; FuelTank; प्रणोदक।

कोड के इस संस्करण में कई महत्वपूर्ण बदलाव हैं। तथ्य यह है कि व्यक्तिगत कार्यों को न केवल अपनी कक्षाओं में इनकैप्सुलेट किया जाता है, वे इस तरह से व्यवस्थित होते हैं जैसे कि पूर्वानुमान और सुसंगत हो जाते हैं। हम कनेक्टिविटी के सिद्धांत का पालन करने के लिए कार्यक्षमता में समान तत्वों को समूहित करते हैं। अब, अगर हमें हैश संरचना से सरणी में बदलकर सिस्टम के सिद्धांत को बदलने की जरूरत है, तो केवल SupplyHold वर्ग का उपयोग करें, हमें अन्य मॉड्यूल को छूने की जरूरत नहीं है। इस प्रकार, यदि रसद प्रभारी अधिकारी अपने अनुभाग में कुछ बदलता है, तो स्टेशन के शेष तत्व अछूते नहीं रहेंगे। साथ ही, अंतरिक्ष यान वर्ग को परिवर्तनों के बारे में पता भी नहीं होगा।

हमारे अंतरिक्ष स्टेशन अधिकारी परिवर्तनों से खुश होने की संभावना रखते हैं, क्योंकि वे उन लोगों से अनुरोध कर सकते हैं जिनकी उन्हें आवश्यकता है। ध्यान दें कि कोड में Report_supplies और Report_fuel जैसे तरीके हैं जो कि SupplyHold और FuelTank कक्षाओं में निहित हैं। यदि रिपोर्ट उत्पन्न होने के तरीके को बदलने के लिए पृथ्वी पूछती है तो क्या होता है? आपको सप्लाईहोल्ड और फ्यूलटैंक दोनों वर्गों को बदलने की आवश्यकता होगी। लेकिन क्या होगा अगर आपको ईंधन और उपभोग्य सामग्रियों को वितरित करने के तरीके को बदलने की आवश्यकता है? आपको सभी समान वर्गों को फिर से बदलना पड़ सकता है। और यह एसआरपी सिद्धांत का उल्लंघन है। चलो इसे ठीक करते हैं।

 class SpaceStation attr_reader :sensors, :supply_hold, :supply_reporter, :fuel_tank, :fuel_reporter, :thrusters def initialize @sensors = Sensors.new @supply_hold = SupplyHold.new @supply_reporter = SupplyReporter.new(@supply_hold) @fuel_tank = FuelTank.new @fuel_reporter = FuelReporter.new(@fuel_tank) @thrusters = Thrusters.new(@fuel_tank) end end class Sensors def run_sensors puts "----- Sensor Action -----" puts "Running sensors!" end end class SupplyHold attr_accessor :supplies attr_reader :reporter def initialize @supplies = {} end def get_supplies @supplies end def load_supplies(type, quantity) puts "----- Supply Action -----" puts "Loading #{quantity} units of #{type} in the supply hold." if @supplies[type] @supplies[type] += quantity else @supplies[type] = quantity end end def use_supplies(type, quantity) puts "----- Supply Action -----" if @supplies[type] != nil && @supplies[type] > quantity puts "Using #{quantity} of #{type} from the supply hold." @supplies[type] -= quantity else puts "Supply Error: Insufficient #{type} in the supply hold." end end end class FuelTank attr_accessor :fuel attr_reader :reporter def initialize @fuel = 0 end def get_fuel_levels @fuel end def load_fuel(quantity) puts "----- Fuel Action -----" puts "Loading #{quantity} units of fuel in the tank." @fuel += quantity end def use_fuel(quantity) puts "----- Fuel Action -----" puts "Using #{quantity} units of fuel from the tank." @fuel -= quantity end end class Thrusters FUEL_PER_THRUST = 10 def initialize(fuel_tank) @linked_fuel_tank = fuel_tank end def activate_thrusters puts "----- Thruster Action -----" if @linked_fuel_tank.get_fuel_levels >= FUEL_PER_THRUST puts "Thrusting action successful." @linked_fuel_tank.use_fuel(FUEL_PER_THRUST) else puts "Thruster Error: Insufficient fuel available." end end end class Reporter def initialize(item, type) @linked_item = item @type = type end def report puts "----- #{@type.capitalize} Report -----" end end class FuelReporter < Reporter def initialize(item) super(item, "fuel") end def report super puts "#{@linked_item.get_fuel_levels} units of fuel available." end end class SupplyReporter < Reporter def initialize(item) super(item, "supply") end def report super if @linked_item.get_supplies.keys.length > 0 @linked_item.get_supplies.each do |type, quantity| puts "#{type} avalilable: #{quantity} units" end else puts "Supply hold is empty." end end end iss = SpaceStation.new iss.sensors.run_sensors # ----- Sensor Action ----- # Running sensors! iss.supply_hold.use_supplies("parts", 2) # ----- Supply Action ----- # Supply Error: Insufficient parts in the supply hold. iss.supply_hold.load_supplies("parts", 10) # ----- Supply Action ----- # Loading 10 units of parts in the supply hold. iss.supply_hold.use_supplies("parts", 2) # ----- Supply Action ----- # Using 2 of parts from the supply hold. iss.supply_reporter.report # ----- Supply Report ----- # parts avalilable: 8 units iss.thrusters.activate_thrusters # ----- Thruster Action ----- # Thruster Error: Insufficient fuel available. iss.fuel_tank.load_fuel(100) # ----- Fuel Action ----- # Loading 100 units of fuel in the tank. iss.thrusters.activate_thrusters # ----- Thruster Action ----- # Thrusting action successful. # ----- Fuel Action ----- # Using 10 units of fuel from the tank. iss.fuel_reporter.report # ----- Fuel Report ----- # 90 units of fuel available. 

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

बेशक, यहां कुछ कक्षाएं अभी भी एक-दूसरे पर निर्भर हैं। तो, SupplyReporter ऑब्जेक्ट SupplyHold पर निर्भर करता है, और FuelReporter FuelTank पर निर्भर करता है। बेशक, बूस्टर को ईंधन टैंक से जोड़ा जाना चाहिए। लेकिन यहां सब कुछ तार्किक दिखता है, और बदलाव करना विशेष रूप से मुश्किल नहीं होगा - एक वस्तु के कोड को संपादित करने से दूसरे पर बहुत अधिक प्रभाव नहीं पड़ेगा।

इस प्रकार, हमने मॉड्यूलर कोड बनाया जहां वस्तुओं / वर्गों में से प्रत्येक की जिम्मेदारियों को ठीक से परिभाषित किया गया है। ऐसे कोड के साथ काम करना कोई समस्या नहीं है; इसका रखरखाव एक सरल कार्य होगा। संपूर्ण "दैवीय वस्तु" हमने एसआरपी में बदल दी है।

स्किलबॉक्स अनुशंसा करता है:

• दो वर्षीय व्यावहारिक पाठ्यक्रम "मैं एक प्रो वेब डेवलपर हूं । "
• ऑनलाइन पाठ्यक्रम "सी # डेवलपर 0 के साथ" ।
• व्यावहारिक वार्षिक पाठ्यक्रम "पीएचपी-डेवलपर 0 से प्रो तक" ।