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