परिचय
रॉबर्ट एल. ग्लास ने तर्क दिया कि व्यवहार सिद्धांत से पहले आता है। विशेष रूप से सॉफ्टवेयर विकास में, व्यवहार सिद्धांत से आगे है, और डेवलपर्स को सबसे अधिक तब लाभ होता है जब वे ठोस कोड के साथ काम करते हैं और अपने हाथों को गंदा करते हैं। इसलिए, हम थोड़ी देर के लिए सिद्धांत और अवधारणाओं को अलग रखेंगे और एक सरल प्रोग्राम पर विचार करेंगे।
टिकट बिक्री अनुप्रयोग को लागू करना
- हम एक छोटे थिएटर के प्रचार के लिए एक छोटा सा कार्यक्रम आयोजित करना चाहते हैं।
- ईवेंट सामग्री: लॉटरी के माध्यम से चुने गए दर्शकों को प्रदर्शन देखने के लिए निःशुल्क निमंत्रण भेजना
- हमें उन दर्शकों के बीच अंतर करना होगा जो कार्यक्रम में भाग लेते हैं और जो नहीं करते हैं।
- ईवेंट विजेता: निमंत्रण को टिकट के लिए एक्सचेंज करें
- ईवेंट हारने वाले: टिकट को पैसे से खरीदें
समस्या क्या है?
रॉबर्ट मार्टिन ने सॉफ्टवेयर मॉड्यूल (आकार की परवाह किए बिना, क्लास, पैकेज या लाइब्रेरी जैसे प्रोग्राम को बनाने वाले किसी भी तत्व) के तीन कार्यों के बारे में बताया।
- संचालन के दौरान ठीक से काम करता है।
- परिवर्तन के लिए मौजूद है।
- बस एक साधारण ऑपरेशन के साथ बदलाव करना संभव होना चाहिए।
- कोड पढ़ने वाले व्यक्ति के साथ संवाद करता है।
- डेवलपर्स को इसे आसानी से पढ़ना और समझना चाहिए।
पिछला टिकट बिक्री अनुप्रयोग पहली बाधा, ठीक से निष्पादित करने को पूरा करता है, लेकिन परिवर्तनशीलता और संचार के उद्देश्यों को पूरा नहीं करता है।
अपेक्षाओं से अलग कोड
आइए संचार के उद्देश्य को पूरा नहीं करने के कारणों पर विचार करें।
- थिएटर क्लास के एंटर() मेथड द्वारा किया गया कार्य
- थिएटर दर्शकों के बैग को खोलकर देखता है कि क्या उसमें निमंत्रण है।
- यदि बैग में निमंत्रण है, तो वह विक्रेता को बताता है कि वह दर्शकों के बैग में बॉक्स ऑफिस में रखे टिकट को रख दे।
- यदि बैग में निमंत्रण नहीं है, तो वह दर्शकों के बैग से टिकट की कीमत के बराबर नकद निकालता है, टिकट खरीदता है और उसे बैग में रख देता है।
- दर्शकों की दृष्टि से, थिएटर नामक तीसरा पक्ष मनमाने ढंग से उनके बैग की जांच करता है, पैसे लेता है और टिकट रखता है।
- विक्रेता के दृष्टिकोण से, थिएटर नामक तीसरा पक्ष बिना अनुमति के बॉक्स ऑफिस में टिकट और नकद की जानकारी में हेरफेर करता है।
- समझने योग्य कोड का अर्थ है कोड जो हमारे अनुमानों से बहुत अधिक विचलित नहीं होता है, और ऊपर वर्णित थिएटर हमारी अपेक्षाओं से विचलित होता है।
- दर्शकों को स्वयं अपने बैग से पैसे निकालकर विक्रेता को भुगतान करना चाहिए और टिकट प्राप्त करना चाहिए।
- विक्रेता को स्वयं बॉक्स ऑफिस से टिकट निकालकर दर्शकों को देना चाहिए और दर्शकों से पैसे लेकर बॉक्स ऑफिस में रखना चाहिए।
- इसके अतिरिक्त, एंटर() मेथड को समझने के लिए, आपको कई विवरणों को याद रखना होगा।
- ऑडियंस के पास बैग है।
- बैग में नकद और टिकट हैं।
- टिकट विक्रेता टिकट कार्यालय में टिकट बेचता है, और टिकट कार्यालय में पैसे और टिकट संग्रहीत होते हैं।
परिवर्तन के प्रति संवेदनशील कोड
एंटर() मेथड दो स्थितियों को मानता है।
- दर्शक हमेशा नकद और निमंत्रण रखने के लिए बैग लेकर चलते हैं।
- विक्रेता केवल टिकट कार्यालय में टिकट बेचता है।
तो नीचे दी गई स्थिति कैसी होगी?
- दर्शक के पास बैग नहीं हो सकता है।
- दर्शक नकद के बजाय क्रेडिट कार्ड का उपयोग कर सकते हैं।
- विक्रेता टिकट कार्यालय के बाहर टिकट बेच सकता है।
उदाहरण के लिए, पहली आवश्यकता को पूरा करने के लिए, हमें ऑडियंस क्लास के बैग ऑब्जेक्ट को हटाना होगा और थिएटर क्लास के एंटर() मेथड को संशोधित करना होगा। ऐसा इसलिए है क्योंकि थिएटर क्लास दर्शकों और विक्रेताओं के बारे में बहुत अधिक जानकारी पर निर्भर करता है, जैसे कि दर्शकों के पास हमेशा बैग होता है और विक्रेता केवल टिकट कार्यालय में टिकट बेचते हैं। यदि इन विवरणों में से कोई भी बदलता है, तो आपको संबंधित क्लास और उस पर निर्भर क्लास (जैसे, थिएटर) दोनों को संशोधित करना होगा।
यह ऑब्जेक्ट के बीच निर्भरता से संबंधित एक समस्या है, और निर्भरता परिवर्तन के प्रभाव का संकेत देती है। हालांकि, ऑब्जेक्ट-ओरिएंटेड डिज़ाइन का लक्ष्य ऑब्जेक्ट्स के समुदाय का निर्माण करना है जो एक-दूसरे पर निर्भर करते हैं और सहयोग करते हैं, इसलिए हमें निर्भरता को बेतरतीब ढंग से नहीं हटाना चाहिए, बल्कि हमें अनुप्रयोग के कार्य को लागू करने के लिए आवश्यक न्यूनतम निर्भरता बनाए रखनी चाहिएऔर अनावश्यक निर्भरता को दूर करना चाहिए।
जब ऑब्जेक्ट के बीच निर्भरता अधिक होती है, तो इसेउच्च युग्मन कहा जाता है, और दो ऑब्जेक्ट के बीच युग्मन जितना अधिक होता है, उनके एक साथ बदलने की संभावना उतनी ही अधिक होती है। इसलिए, डिज़ाइन का लक्ष्य ऑब्जेक्ट के बीच युग्मन को कम करना और परिवर्तन के अनुकूल डिज़ाइन बनाना है।
डिजाइन में सुधार
थिएटर को यह जानने की आवश्यकता नहीं है कि क्या दर्शक बैग लेकर आते हैं या विक्रेता टिकट कार्यालय में टिकट बेचते हैं। थिएटर केवल यह चाहता है कि दर्शक थिएटर में प्रवेश करें। इसलिए, हमें दर्शकों को स्वयं अपने बैग में रखे नकद और निमंत्रण को संभालने देना चाहिए और विक्रेता को स्वयं बॉक्स ऑफिस में रखे टिकट और बिक्री मूल्य को संभालने देना चाहिए ताकि वे स्वायत्त हो सकें।
स्वायत्तता बढ़ाएँ
एक ऑब्जेक्ट जिसका काम केवल उसके निकट से संबंधित कार्यों तक सीमित होता है और असंबंधित कार्यों को दूसरे ऑब्जेक्ट्स को सौंप देता है, उसे उच्च एकीकरण वाला ऑब्जेक्ट कहा जाता है। स्वायत्त ऑब्जेक्ट बनाकर जो अपने डेटा को स्वयं संभालते हैं, हम युग्मन को कम कर सकते हैं और एकीकरण को बढ़ा सकते हैं।
प्रक्रिया-उन्मुख और वस्तु-उन्मुख
- प्रक्रिया-उन्मुख
- थिएटर का एंटर() मेथड एक प्रक्रिया है, और ऑडियंस, टिकट विक्रेता, बैग और टिकट कार्यालय डेटा हैं।
- प्रक्रिया और डेटा को अलग-अलग मॉड्यूल में रखने की विधि को प्रक्रिया-उन्मुख प्रोग्रामिंग कहा जाता है।
- इसमें बहुत सारे कोड हैं जो हमारे अंतर्ज्ञान के विपरीत हैं। (उदाहरण के लिए, दर्शक स्वयं पैसे और निमंत्रण का प्रबंधन करते हैं।)
- डेटा में परिवर्तन के प्रभाव को सीमित करना मुश्किल है।
- जिम्मेदारी केंद्रीकृत है। (थिएटर सब कुछ नियंत्रित करता है)
- वस्तु-उन्मुख
- डेटा और प्रक्रिया को एक ही मॉड्यूल में रखने की विधि को ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग कहा जाता है।
- हम अपने अंतर्ज्ञान के अनुसार कोड लिख सकते हैं।
- इसे इनकैप्सुलेशन के माध्यम से डेटा में परिवर्तन के प्रभाव को प्रभावी ढंग से सीमित किया जा सकता है।
- प्रत्येक वस्तु स्वयं के लिए जिम्मेदार है।
इसे और बेहतर बनाया जा सकता है।
- ऑडियंस क्लास के बैग क्लास को अभी भी ऑडियंस क्लास द्वारा नियंत्रित किया जाता है, इसलिए हमें बैग क्लास को एक स्वायत्त ऑब्जेक्ट बनाना होगा।
- टिकट विक्रेता क्लास का टिकट कार्यालय भी टिकट विक्रेता द्वारा नियंत्रित किया जाता है। हमें टिकट कार्यालय को एक स्वायत्त ऑब्जेक्ट बनाना होगा।
- हालांकि, परिवर्तन के बाद, टिकट कार्यालय ऑडियंस के साथ अतिरिक्त युग्मन में आ गया है।
- इस तरह, डिज़ाइन में समझौता शामिल होता है। इस मामले में, हम ऑडियंस के साथ युग्मन को कम करने के लिए टिकट कार्यालय को कुछ हद तक निष्क्रिय ऑब्जेक्ट बनाने पर सहमत हो सकते हैं।
हाँ, यह झूठ है!
- वास्तविक दुनिया में, भले ही वे निष्क्रिय हों, जब वे ऑब्जेक्ट-ओरिएंटेड दुनिया में प्रवेश करते हैं, तो वे सभी सक्रिय और स्वायत्त हो जाते हैं।
- निष्क्रिय ऑब्जेक्ट्स को मानवीकृत करने और उन्हें हंसने, बोलने और गुस्सा करने वाले लोगों के रूप में सोचने का प्रयास करना उचित है।
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन
डिजाइन की आवश्यकता क्यों है?
- डिज़ाइन कोड को व्यवस्थित करने के तरीके के बारे में है।
- एक अच्छा डिज़ाइन वर्तमान आवश्यकताओं को पूरा करता है और भविष्य के परिवर्तनों को आसानी से स्वीकार करता है।
ऑब्जेक्ट-ओरिएंटेड डिज़ाइन
- परिवर्तन योग्य कोड समझने में आसान कोड है।
- ऑब्जेक्ट-ओरिएंटेड प्रतिमान हमें दुनिया को देखने के तरीके से कोड लिखने में मदद करता है।
- ऑब्जेक्ट स्वायत्त इकाइयाँ हैं जो अपने डेटा के लिए जिम्मेदार हैं।
- एक अच्छा ऑब्जेक्ट-ओरिएंटेड डिज़ाइन सहयोगी ऑब्जेक्ट्स के बीच निर्भरता का प्रबंधन करता है।
स्रोत
- ऑब्जेक्ट
टिप्पणियाँ0