हमें ओओपी की आवश्यकता क्यों है?

1. कंपनी का इतिहास

मैं आपको एक कहानी बताना चाहता हूं जो दर्शाती है कि कैसे OOP बड़े सिस्टम की जटिलता से लड़ने में मदद करता है। OOP के उद्देश्य को समझने के लिए यह आपके लिए आवश्यक है ।

एक बार एक छोटी सी कंपनी थी जो अंतरिक्ष शिपिंग सेवाएं प्रदान करती थी ...

चलिए इसे गैलेक्सी रश कहते हैं। इसमें 5 लोगों को रोजगार मिला। एक वित्त में काम करता था, दूसरा एक गोदाम में काम करता था, तीसरा डिलीवरी करता था, चौथा विज्ञापन संभालता था और पाँचवाँ पूरे उद्यम का प्रबंधन करता था।

वे बहुत मेहनती थे और हर चीज में सफल होते थे। कंपनी की अच्छी प्रतिष्ठा थी और बहुत पैसा कमाया। लेकिन हर साल अधिक से अधिक आदेश होते थे, इसलिए बॉस को अतिरिक्त कर्मचारी रखने पड़ते थे। वेयरहाउस के लिए कई और, डिलीवरी के लिए कई और, वित्त के लिए एक और और कंपनी की बाजार हिस्सेदारी बढ़ाने के लिए एक अतिरिक्त विज्ञापन विशेषज्ञ।

और तभी समस्याएं शुरू हुईं। और भी लोग थे , और वे एक दूसरे के रास्ते में आने लगे।

विपणक एक नए विज्ञापन अभियान पर बैंक खाते को खाली कर देता है, इसलिए उन उत्पादों को खरीदने के लिए कोई पैसा नहीं है जिन्हें तत्काल भेजने की आवश्यकता है।

वेयरहाउस में 10 नई हाइपर ड्राइव हैं जो महीने में एक बार ग्राहक को भेजी जाती हैं। एक कूरियर आया और एक अलग ग्राहक के लिए एक हाइपर ड्राइव ले गया, जिसके कारण 10 हाइपर ड्राइव के नियमित ऑर्डर में एक महीने की देरी हो गई। पहले कूरियर को दूसरे कूरियर द्वारा भरे जा रहे दूसरे ऑर्डर के बारे में पता नहीं था।

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

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

कुछ करना था, इसलिए बॉस ने मोनोलिथिक कंपनी को कुछ विभागों में बांटने का फैसला किया। उन्होंने एक नौवहन विभाग, एक विपणन विभाग, एक खरीद विभाग, एक वित्त विभाग और एक सूची विभाग बनाया। अब कोई भी अंतरिक्ष यान नहीं ले सकता था। शिपिंग विभाग के प्रमुख ने डिलीवरी के बारे में सभी जानकारी प्राप्त की और सबसे लाभदायक ऑर्डर के साथ कूरियर को जहाज जारी किया। इसके अतिरिक्त, वेयरहाउस ने कोरियर को अपनी इच्छानुसार कोई भी सामान लेने की अनुमति नहीं दी। इसके बजाय, वेयरहाउस से उत्पाद चुनना एक नियंत्रित प्रक्रिया बन गई। यदि वित्त विभाग को पता होता कि जल्द ही खरीदारी होगी, तो वह मार्केटिंग अभियान के लिए धन जारी नहीं करेगा। प्रत्येक विभाग का एक सार्वजनिक चेहरा होता था - विभाग प्रमुख।प्रत्येक विभाग की आंतरिक संरचना का अपना व्यवसाय था। यदि कोई कूरियर उत्पाद प्राप्त करना चाहता था, तो वह गोदाम प्रबंधक के पास गया, गोदाम में नहीं। यदि कोई नया आदेश आता है, तो वह शिपिंग विभाग के प्रमुख ( public-facing representative) द्वारा प्राप्त किया जाता है न कि किसी कूरियर ( someone not authorized to interact with the other departments) द्वारा।

दूसरे शब्दों में, बॉस ने संसाधनों और कार्यों को समूहों (विभागों) में समेकित किया , और दूसरों को विभागों की आंतरिक संरचनाओं में हस्तक्षेप करने से भी मना किया। अंतर्विभागीय बातचीत को एक विशिष्ट व्यक्ति के माध्यम से जाना था।

ओओपी के दृष्टिकोण से , यह कार्यक्रम को वस्तुओं में विभाजित करने से ज्यादा कुछ नहीं है । विधियों और चरों का एक अखंड कार्यक्रम वस्तुओं से युक्त एक कार्यक्रम बन जाता है। और वस्तुओं में चर और विधियाँ हैं।

समस्या यह थी कि कोई भी कर्मचारी किसी भी संसाधन के साथ काम कर सकता था और किसी भी अन्य कर्मचारी को आदेश दे सकता था, वह भी बिना निरीक्षण या नियंत्रण के। हमने एक छोटा सा प्रतिबंध लगाया, लेकिन अधिक आदेश प्राप्त किया। और हम सब कुछ बेहतर ढंग से नियंत्रित करने में भी सक्षम थे।

यह अपने शुद्धतम रूप में फूट डालो और जीतो है।

2. प्रोग्राम कैसे बनाए जाते हैं

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

प्रोग्रामिंग में बहुत बार, आप कुछ ऐसा नहीं कर सकते जिस तरह से आप मूल रूप से चाहते थे और आपको बहुत कुछ करना चाहिए। ग्राहकों की आवश्यकताएं और भी अधिक बार बदलती हैं।

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

उत्पाद की सफलता ग्राहक को एक नया संस्करण जारी करने के लिए प्रेरित करेगी, और फिर दूसरा और दूसरा। और, ज़ाहिर है, आपको केवल मौजूदा उत्पाद में "छोटे बदलाव" जोड़ने की ज़रूरत है। तो आप देख सकते हैं कि उत्पाद विकास निरंतर परिवर्तनों का एक क्रम है। केवल समय का पैमाना अलग है। एक नया संस्करण सप्ताह में एक बार, महीने में एक बार या हर छह महीने में एक बार जारी किया जा सकता है।

और इस सब से हम क्या निष्कर्ष निकाल सकते हैं? उत्पाद की आंतरिक संरचना को इस तरह से बनाए रखने की आवश्यकता है जिससे न्यूनतम पुनर्कार्य के साथ महत्वपूर्ण (और मामूली) परिवर्तन किए जा सकें।

वस्तु सामंजस्य

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

अब हम वस्तुओं (बिंदुओं) को समूहों में जोड़ेंगे। बिंदुओं को समूहीकृत किया जाना चाहिए यदि उनके बीच के संबंध अन्य बिंदुओं की तुलना में बहुत अधिक तीव्र हैं। यदि एक बिंदु से अधिकांश तीर अपने समूह में अन्य बिंदुओं पर जाते हैं, तो समूह सही तरीके से बने थे। हम कहते हैं कि एक समूह के भीतर के बिंदुओं में उच्च सामंजस्य होता है जबकि विभिन्न समूहों के बिंदुओं में कम सामंजस्य होता है।

ढीला-युग्मन सिद्धांत

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

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

अच्छा चुना। लेकिन क्या होगा अगर उन्हें अच्छी तरह से नहीं चुना गया है? तब परिवर्तन की क्षमता जल्दी समाप्त हो जाती है और आपको पूरी प्रणाली को फिर से करना होगा। यह समय-समय पर किया जाना है। आप भविष्य की भविष्यवाणी नहीं कर सकते, लेकिन आप रेडोस की संख्या को न्यूनतम रख सकते हैं।

अमूर्तता का सिद्धांत

विभागों को कैसे संरचित किया जाता है और वे कैसे बातचीत करते हैं, यह चुनना " अमूर्तता का सिद्धांत " है। प्रोग्रामिंग में, इसका उपयोग किसी प्रोग्राम को घटक भागों में तोड़ने का सबसे अच्छा तरीका निर्धारित करने के लिए किया जाता है और उन भागों को कैसे इंटरैक्ट करना चाहिए। हम सिद्धांत को फिर से लागू कर सकते हैं, परिणामी भागों को भागों में विभाजित कर सकते हैं, जब तक कि हम प्रोग्राम को अलग-अलग वर्गों में तोड़ नहीं देते।

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