"नमस्कार, अमीगो! मैं आपको ओओपी के एक और लाभ के बारे में बताना चाहता हूं। आप देखते हैं, कार्यक्रम इमारतों की तुलना में जानवरों की तरह अधिक हैं। वे बनाए नहीं गए हैं, वे बड़े हो गए हैं। विकास का अर्थ है निरंतर परिवर्तन। निर्माण में, आप कर सकते हैं एक अच्छी योजना है और इसे एक टी तक पालन करें। लेकिन सॉफ्टवेयर विकास में, ऐसा नहीं है।"
बहुत बार, आप अपने इच्छित तरीके से कुछ नहीं कर सकते हैं, और आपको अपने कार्यक्रम पर बहुत अधिक कार्य करना होगा। और इससे भी अधिक बार, ग्राहक की आवश्यकताएं बदलती हैं।
"लेकिन क्या होगा यदि ग्राहक वास्तव में विस्तृत विनिर्देश प्रदान करता है?"
"समय के साथ क्या होता है, इस पर एक नज़र डालें। यदि कोई उत्पाद सफल होता है, तो ग्राहक एक नया संस्करण जारी करना चाहेगा, और फिर दूसरा, और दूसरा। और निश्चित रूप से, आपको कुछ « छोटे बदलाव » करने होंगे मौजूदा उत्पाद। इसलिए सॉफ्टवेयर विकास परिवर्तनों की एक लंबी श्रृंखला है। केवल ताल अलग है। एक नया संस्करण हर हफ्ते, महीने में एक बार या हर छह महीने में जारी किया जा सकता है।
"तो हम इस सब से क्या निष्कर्ष निकालते हैं?"
"उत्पाद की आंतरिक संरचना को इस तरह से बनाए रखा जाना चाहिए जिससे न्यूनतम पुनर्कार्य के साथ बड़े (और मामूली) परिवर्तन किए जा सकें।"
"आप उसे कैसे करते हैं?"
"हम पहले ही इस बारे में बात कर चुके हैं कि कैसे एक प्रोग्राम में ऑब्जेक्ट्स होते हैं जो एक दूसरे के साथ इंटरैक्ट करते हैं। बोर्ड पर हमारे प्रोग्राम की सभी वस्तुओं का प्रतिनिधित्व करने के लिए मोटे डॉट्स का उपयोग करें। हम प्रत्येक ऑब्जेक्ट (डॉट) से सभी ऑब्जेक्ट्स के लिए तीर खींचेंगे। (डॉट्स) जिसके साथ यह इंटरैक्ट करता है।"
अब वस्तुओं (बिंदुओं) को समूहों में मिलाते हैं। डॉट्स एक ही समूह से संबंधित हैं यदि वे अन्य डॉट्स की तुलना में एक दूसरे से बहुत अधिक जुड़े हुए हैं। यदि डॉट के अधिकांश तीर उसके समूह में डॉट्स पर इंगित करते हैं, तो हमने वस्तुओं को सही ढंग से समूहित किया है। एक ही समूह के बिंदुओं को कसकर युग्मित कहा जाता है, जबकि विभिन्न समूहों में बिंदुओं को शिथिल रूप से जोड़ा जाता है।
इसे « ढीले युग्मन का सिद्धांत » कहा जाता है। एक कार्यक्रम को कई भागों में विभाजित किया जाता है, अक्सर परतें, जिसका तर्क उनकी आंतरिक संरचना से मजबूती से बंधा होता है और अन्य परतों/भागों से कमजोर रूप से बंधा होता है। परतों के बीच अंतःक्रिया आमतौर पर अत्यधिक विभाजित होती है। एक परत अपनी कक्षाओं के केवल एक छोटे उपसमुच्चय का उपयोग करके दूसरी परत को कॉल कर सकती है।
"वही 'श्रम विभाजन' सिद्धांत, लेकिन बड़े पैमाने पर?"
"सटीक रूप से। यह हमें एक विभाग को पुनर्गठित करने, इसे और अधिक कुशल बनाने, और अधिक लोगों को नियुक्त करने की अनुमति देता है, और यदि हम अंतर-विभागीय प्रोटोकॉल नहीं बदलते हैं, तो हमारे सभी परिवर्तन स्थानीय होंगे। पूरे सिस्टम को फिर से काम करने की जरूरत नहीं है। प्रत्येक विभाग अपने आंतरिक मामलों को इस तरह से अनुकूलित कर सकता है यदि विभागीय बातचीत के तंत्र को अच्छी तरह से चुना जाए।"
"यदि वे अच्छी तरह से चुने गए हैं। और क्या होगा यदि वे अच्छी तरह से नहीं चुने गए हैं?"
'फिर आप जल्दी से परिवर्तन करने के लिए « विगल रूम » से बाहर निकल जाएंगे, और पूरे सिस्टम को फिर से काम करना होगा। ऐसा समय-समय पर होता रहता है। हम भविष्य की भविष्यवाणी नहीं कर सकते हैं, लेकिन हम प्रोग्राम को फिर से लिखने की संख्या को कम कर सकते हैं।"
"ठीक है। मुझे कार्यक्रम को इस तरह विभाजित करने का लाभ दिखाई देता है, लेकिन ओओपी तस्वीर में कैसे आता है?"
"जब हम चुनते हैं कि विभागों की संरचना कैसे की जाए और वे कैसे परस्पर क्रिया करेंगे, तो हम ' अमूर्तता के सिद्धांत ' को लागू करते हैं। प्रोग्रामिंग में, अमूर्तता का उपयोग कार्यक्रम को विभाजित करने का सबसे अच्छा तरीका निर्धारित करने के लिए किया जाता है और भागों को कैसे परस्पर क्रिया करनी चाहिए। यह सिद्धांत कर सकते हैं घटक भागों पर भी बार-बार लागू किया जाना चाहिए जब तक कि हम कार्यक्रम को अलग-अलग वर्गों में तोड़ न दें।"
"और इन भागों की आंतरिक संरचना को छिपाना, और कड़ाई से सीमित करना कि वे अन्य भागों के साथ कैसे बातचीत करते हैं - यह एनकैप्सुलेशन है , है ना?"
"बिल्कुल सही। एनकैप्सुलेशन और अमूर्त OOP की आधारशिला हैं। एक अच्छे कार्यक्रम को इन दो सिद्धांतों का पालन करना चाहिए। बाद में हम अन्य सिद्धांतों पर एक नज़र डालेंगे और उनके लाभों को समझेंगे।"
"अच्छी चीजें। मैं इंतजार नहीं कर सकता!"
GO TO FULL VERSION