क्या OOP आसान या कठिन होता जा रहा है? [बन्द है]

Question

जब ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग की अवधारणाओं को प्रोग्रामर के लिए सालों पहले पेश किया गया था तो यह दिलचस्प लगता है और प्रोग्रामिंग क्लीनर था। OOP इस तरह था

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);

आत्म-वर्णनात्मक नाम के साथ समझना आसान था।

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

नोट: मैं सर्वोत्तम प्रथाओं के खिलाफ नहीं हूं जो सहयोग, परीक्षण और एकीकरण को आसान बनाता है

Comments

एक अच्छा सॉफ्टवेयर आर्किटेक्चर बनाना हमेशा कठिन रहा है और हमेशा (सबसे अधिक संभावना) होगा।

— जोहान्स

मैं नाम बदलने होगा addItemके लिए addऔर removeItemके लिए remove। क्योंकि यह पढ़ना आसान है। stock.add(item)या stock.remove(item)। और अधिक ओओपी उन्मुख।

— राजपीठिया

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

— कोनराड रुडोल्फ

आप अपने तर्क से सेब और नारंगी की तुलना कर रहे हैं, तो अनिवार्य प्रोग्रामिंग (यानी लूप और अगर-हालत) हमारे पास आज की सभी चीजों की तुलना में सरल है। इम्पीरेटिव प्रोग्रामिंग कक्षाओं / ओओपी के लिए बिल्डिंग ब्लॉक है, और कक्षाएं / ओओपी डिजाइन पैटर्न के लिए बिल्डिंग ब्लॉक हैं। जैसे-जैसे आप प्रगति करते हैं चीजें और अधिक जटिल होती जाती हैं क्योंकि आप अधिक जटिल समस्याओं को हल कर रहे हैं।

— रेयान

@ लिरियन - मैंने देखा है कि समस्याएं सिर्फ इसलिए जटिल हो गई हैं क्योंकि कोई भी प्रभारी उन्हें सरल अनिवार्य प्रोग्रामिंग के साथ हल करने में सक्षम नहीं था और ओओपी के शीर्ष पर डिजाइन पैटर्न के साथ उन पर हमला किया जो सरल अनिवार्य समाधान के शीर्ष पर थे जिन्हें अकेले लागू किया जाना चाहिए था।

— मौविसील

Answer 1

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

तो यह क्यों है कि आप ओओपी को आज से अधिक जटिल मानते हैं जब आपने इसका उपयोग करना शुरू किया था।

एक कारण यह हो सकता है कि जिस कोड को आप उजागर कर रहे हैं, वह अधिक जटिल हो जाता है - इसलिए नहीं कि ओओपी अधिक जटिल हो गया है, बल्कि इसलिए कि आप सीखने की सीढ़ी पर आगे बढ़ चुके हैं, और बड़े और अधिक जटिल कोड बेस पढ़ने के लिए प्राप्त करते हैं।

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

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

इस वजह से, अधिकांश आधुनिक ओओपी भाषाएँ अन्य प्रतिमानों से सुविधाओं को शामिल करती हैं, जो उन्हें अधिक अभिव्यंजक और अधिक शक्तिशाली बनाती हैं, लेकिन अधिक जटिल हैं। C # इसके लिए प्रमुख उदाहरण है: इसकी स्पष्ट OOP जड़ें हैं, लेकिन अन्य प्रतिमानों से उत्पन्न प्रतिनिधियों, घटनाओं, प्रकार के अनुमान, प्रकार के डेटा प्रकार, विशेषताएँ, अनाम फ़ंक्शन, लंबोदर भाव, जेनरिक आदि जैसी विशेषताएं, सबसे विशेष रूप से कार्यात्मक प्रोग्रामिंग हैं। ।

Comments

इसलिए डिजाइन पैटर्न ने जटिलताओं को जोड़ा। मतलब डिजाइन पैटर्न जरूरी OOP नहीं है लेकिन OOP बढ़ाने के लिए जोड़ा गया है।

— ट्यूनीज़ फासिप

@tunmisefasipe: बिलकुल नहीं। डिजाइन पैटर्न मानक समस्याओं के लिए बस सिद्ध समाधान हैं; वे OOP के लिए एक 'जोड़' नहीं हैं, बल्कि एक परिणाम है। जटिलता पहले से ही थी; डिजाइन पैटर्न सिर्फ इसे से निपटने के लिए रसोई की रणनीति प्रदान करते हैं।

— tdammers

Answer 2

नहीं, यह अधिक इंजीनियर बन रहा है। और आप सही हैं- SO C ++ चैट में हम अक्सर AbstractSingletonFactoryProxyBeanBridgeAdapterManagers Java कोड में देखते हैं।

लेकिन अच्छा कोड इस संपत्ति का प्रदर्शन नहीं करता है। अच्छे कोड में, आप अभी भी कह सकते हैं

std::stack<int> s;
s.push(5);
s.pop();

Comments

आपके पोस्ट से स्पष्ट नहीं है, लेकिन मुझे लगता है कि ओवर-इंजीनियरिंग जावा और सी ++ कोड दोनों में स्पष्ट है । यह स्वयं के द्वारा या तो भाषा की संपत्ति नहीं है, लेकिन प्रोग्रामर के अभ्यास की ... दोनों भाषाएं अच्छे कोड लिखने की अनुमति देती हैं, हालांकि न तो (आईएमओ) इसके लिए विशेष रूप से अनुकूल है :) जावा में फ्रेमवर्क, चूसना, अफसोस की बात है।

— एंड्रेस एफ।

: ओवर-इंजीनियरिंग के बारे में बात करते हुए इस सूत्र अनिवार्य है discuss.joelonsoftware.com/default.asp?joel.3.219431

— सुरक्षित

@AndresF। सच है, लेकिन आप इसे सी ++ कोड में इतना अधिक नहीं पाते हैं, जबकि आप जावा और .NET में करते हैं: एमवीवीएमवीएमएमडी डिजाइन पैटर्न msdn.microsoft.com/en-us/magazine/hh96521.aspx के रूप में देखें आप 'सिंपल कोड' कैसे लेते हैं और इसे आसान बनाने के लिए इस पर एक डिज़ाइन पैटर्न का थप्पड़ लगाते हैं और फिर डिज़ाइन पैटर्न पर एक और डिज़ाइन पैटर्न को थप्पड़ मारते हैं, क्योंकि मूल पैटर्न उतना सरल नहीं था। ओवर-इंजीनियरिंग अधिक से अधिक आम होता जा रहा है।

— gbjbaanb

मैं "बिट" बनने के साथ बहस करूँगा। ओवर-इंजीनियरिंग इंजीनियरिंग जितनी पुरानी है।

— रोबोट

@AndresF। हम चैट में विशेष रूप से जावा-विरोधी हैं, लेकिन यह सच है कि जावा, सी ++ से अधिक , ओवर-इंजीनियरिंग को प्रोत्साहित करता है क्योंकि यह इसे और अधिक किफायती (जीसी) बनाता है, और लोकप्रिय उद्यम जावा पुस्तकालयों ने इस शैली को लोकप्रिय बनाया है, जैसा कि आपने नोट किया है। स्वयं।

— कोनराड रुडोल्फ

Answer 3

मैं कहूंगा कि आपके द्वारा बताई गई "जटिलता" की समस्याओं का ओओपी से कोई लेना-देना नहीं है। इसका सरोकार अलग-अलग चिंताओं से है।

कई साल पहले मैंने एक सिस्टम पर काम किया था, जहाँ डोमेन वर्ग के पास डेटाबेस से खुद को लोड करने की जिम्मेदारी थी, उदा

var userId = Request.QueryString["UserID"].ToInt();
var user = new User(userId);
user.Name = ...;
...
user.Save();

यह बहुत स्पष्ट कोड है। इसे समझने में कोई दिक्कत नहीं। हालांकि समस्या कोड के परीक्षण की इकाई में होगी। अर्थात्, मैं Userडेटाबेस से एक को लोड किए बिना कक्षा का परीक्षण कैसे करूंगा ? और डेटाबेस तक पहुंच के बिना मैं इस वेब अनुरोध हैंडलिंग कोड का परीक्षण कैसे करूंगा? यह बस संभव नहीं है।

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

इसलिए यदि हम आपके द्वारा लिखे गए उदाहरण पर वापस जाते हैं, तो आप इसे बनाने के बाद स्टॉक के साथ क्या करेंगे? डेटाबेस में इसे सहेजें

Stock stock = new Stock();
stock.addItem(item);
stock.removeItem(item);
this.StockRepository.Add(stock);

एक लाल! OOP की प्रगति में कोई गति नहीं है जो यह बताती है कि यह किसी भी कठिन होना चाहिए। दुर्भाग्य से, यदि आप अपने डेटा एक्सेस कोड के लिए OR मैपर का उपयोग करना चुनते हैं, तो आप इस समस्या में भाग सकते हैं कि OR मैपर आपके सिस्टम को लिखने के तरीके पर प्रतिबंध लगा रहा है। लेकिन वह दूसरी बात है।

यदि आप इन पैटर्न के लिए नए हैं, तो आपको प्रोग्रामिंग की एक नई शैली सीखने की आवश्यकता हो सकती है। लेकिन प्रोग्रामिंग की यह शैली किसी भी तरह से पुराने स्कूल ओओपी प्रोग्रामिंग से अधिक कठिन नहीं है।

Comments

आप अपने भंडार को स्थापित करने के लिए किए गए प्रयास को जानते हैं। हालांकि इसे स्थापित करने के बाद, यह पुन: प्रयोज्य हो जाता है।

— ट्यूनीज़ फेसपाइप

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

— gbjbaanb

@ जीबीजैनब: हमारे पास पहले से ही है, इसके एकीकरण / कार्यात्मक परीक्षण। यूनिट परीक्षण एक अलग लेकिन समान रूप से आवश्यक उद्देश्य प्रदान करता है

— केविन

@ जीबीजैनब - हमारे पास पहले से ही सिस्टम-वाइड / स्वीकृति परीक्षण के लिए महान उपकरण हैं, जैसे रेल्स प्लेटफॉर्म पर ककड़ी। लेकिन जो टीमें वास्तव में अच्छी हैं और बहुत कम बग लिखती हैं, लेकिन वे तेजी से उद्धार करती हैं, वे बहुत सारे यूनिट परीक्षण लिखते हैं, और बस कुछ सिस्टम-वाइड परीक्षण। "परीक्षण त्रिभुज" के बारे में देखें, जैसे यहाँ jonkruger.com/blog/2010/02/08/the-automated-testing-triangle

— पीट

Answer 4

न तो। हमारी समस्याएं वास्तव में नहीं बदली हैं; स्वीकार्य कोड के लिए बार उठाया गया है।

उपरोक्त प्राप्त करने के लिए आपको कई कक्षाएं (जैसे अमूर्त, कारखाना, डीएओ आदि) बनाने और कई इंटरफेस लागू करने पड़ सकते हैं

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

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

Answer 5

"OO को परिचय" उदाहरण एक वास्तविक दुनिया आवेदन की तुलना में बहुत सरल हैं। उपरोक्त प्राप्त करने के लिए आपको केवल एक वर्ग की आवश्यकता है। समस्या यह है कि यह बहुत कुछ नहीं करता है। कुछ डिज़ाइन पैटर्न करीब आने की कोशिश करते हैं (जैसे ActiveRecord।) लेकिन अंततः, कोई भी उदाहरण जो तुच्छ नहीं है, एक से अधिक वर्ग होगा; वह ठीक है।

Comments

यह भी ध्यान दें कि फ्रेमवर्क समय के साथ बनता है। तो हाँ, प्रोग्रामिंग को अधिक ज्ञान की आवश्यकता है। इसका अर्थ यह भी है कि व्यक्ति कम समय में अधिक कर सकता है।

— जीन बॉयर्सकी

Answer 6

आज ओओ का उपयोग करने वाली प्रोग्रामिंग भाषाएं जटिल आवश्यकताओं और वातावरण को पूरा करने की कोशिश कर रही हैं जो बदलते रहते हैं। OO अपने अडॉप्टरों को जटिलता के स्तरों (अन्य विशेषताओं के बीच) को छिपाने की अनुमति देता है ताकि कोडिंग अधिक स्पष्ट और निर्माण और समझने में आसान हो जाए। हालाँकि, यह सुविधा हमेशा आउट ऑफ़ बॉक्स नहीं होती है। आपके उदाहरण में, OO ने आपको संग्रह में आइटम प्रबंधित करने के लिए एक विधि प्रदान करके मुझसे कुछ विवरण छिपाने की अनुमति दी है और "AddItem" विधि का उपयोग करके इसे जारी रखने के लिए भी हो सकता है। जटिलता को छिपाने में प्रयास करने के परिणामस्वरूप उपयोग करने में आसान और एक पुन: प्रयोज्य फ्रेमवर्क हो सकता है जो जीवन को सरल बनाता है। उदाहरण के लिए, कई ओआरएम कार्यान्वयन आपको डेटाबेस के साथ संवाद करने की अनुमति देते हैं, बिना प्रोग्रामर एसक्यूएल विवरण लिखे। यह वास्तव में शक्तिशाली है और यह डेवलपर पर सरल बनाता है।

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

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

Comments

स्पष्ट अंक। मैं YAGNI को जानता हूं। KISS क्या है?

— ट्यूनीज़ फेसपाइप

@tunmisefasipe, KISS एक डिजाइन सिद्धांत के लिए एक संक्षिप्त नाम है। : मूल शब्द (रेफरी "यह सरल (बेवकूफ) रखें" कर रहे हैं en.wikipedia.org/wiki/KISS_principle लेकिन एक और अधिक विनम्र शब्दों हो "यह रखें तो सरल" हो सकता है)।

— NoChance

@tunmisefasipe - KISS = यह सरल रखें, बेवकूफ। एक वाक्यांश जिसे मैं अपने आप को दोहराता हूं, और कभी भी, और कभी भी, और यह अभी भी हमेशा डूबने के लिए प्रतीत नहीं होता है

— माइकल कोहेन

@MichaelKohne, हम सब करते हैं! मेरा अनुमान है कि चीजों को सरल बनाने में सक्षम होना एक कला है। E = M C C बहुत संक्षिप्त रूप में एक पूरी बात कहता है!

— NoChance

Answer 7

संक्षिप्त उत्तर : हां, क्योंकि आप कठिन समस्याओं से निपटते हैं।

लंबे उत्तर (दृढ़ता से पक्षपाती) : मेरे लिए डिजाइन पैटर्न आमतौर पर इंगित करता है कि कुछ प्रतिमान में दिए गए क्षेत्र में समस्याएं हैं। OOP पैटर्न OOP की समस्याओं से निपटते हैं (निचले स्तर पर जावा पैटर्न जावा की समस्याओं से निपटते हैं), FP पैटर्न FP की समस्याओं से निपटते हैं।

प्रोग्रामिंग के दौरान आपकी अलग प्राथमिकताएँ हो सकती हैं। आप सही कार्यक्रम करना चाहते हैं, हो सकता है कि आप समय-समय पर बाज़ार, सबसे तेज़ कार्यक्रम संभव हो, एक लंबी अवधि के लिए दीर्घकालिक रख-रखाव या तत्काल रखरखाव बनाए रखना चाहते हों। आपके द्वारा किए जा रहे झाड़-झंखाड़ के आधार पर आप बहुत भिन्न होंगे - यदि आप पावर प्लांट के प्रोग्रामिंग कंट्रोलर हैं, तो आप इसे पहली बार करना चाहते हैं और अब हर बार बगफिक्स नहीं करते हैं और ("क्या हर बार प्रेस करने पर मेल्टडाउन होता है Ctrl+Alt+Del?")। यदि आप एचपीसी में हैं तो तर्क सापेक्ष रूप से सरल हो सकता है, लेकिन आप इसे जितनी जल्दी हो सके उतनी तेजी से निष्पादित करना चाहते हैं आदि आदि। इसके अलावा कुछ प्रतिमान कुछ समस्याओं को बेहतर कहते हैं (जैसे एआई और तर्क प्रोग्रामिंग, डेटा और संबंधपरक डेटाबेस)।

OOP साधारण मामलों में कुछ 'बहुत अच्छा' है और यह "वास्तविक लाइव मॉडलिंग" कहानी है। उदाहरण के लिए OOP के बारे में पहली पुस्तक में मैंने पढ़ा था कि कक्षाएं थीं Person, Employeeऔर रिश्ते के Managerसाथ is-a। अब तक तो अच्छा है लेकिन क्या होगा अगर कर्मचारी को प्रबंधक के रूप में पदोन्नत किया जाए?

दूसरी ओर अन्य प्रतिमानों में कठिन प्रथम-कालिक पाठ होते हैं - उदाहरण के लिए एफपी अपरिवर्तनीय चर के साथ (मजेदार बात यह है कि जिन लोगों को प्रोग्रामिंग के साथ अनुभव था, उन्हें अक्सर उन लोगों की तुलना में सीखना कठिन लगता है जिनके लिए यह पहली भाषा है) - हालांकि अंततः वे हैं OOP से ज्यादा कठिन नहीं है। शुद्ध कार्यों का परीक्षण तुच्छ है और हास्केल / स्काला / में ... आपके पास ऐसे उपकरण हैं जो आपके लिए परीक्षण उत्पन्न करते हैं।

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

पी पी एस। हां - डिजाइन पैटर्न का उपयोग करें - वे ओओपी प्रोग्रामिंग को अंततः सरल बनाते हैं।

PPPS। मैंने OOP को OOP अनिवार्य प्रोग्रामिंग के पर्याय के रूप में इस्तेमाल किया।

Answer 8

मुझे लगता है कि इसके दस्तावेजों और उदाहरणों का मामला अधिक यथार्थवादी बन रहा है।

प्रारंभिक OOP पुस्तकें (विशेष रूप से प्रारंभिक जावा पुस्तकें) ने एप्लिकेशन प्रोग्रामिंग का एक बेतुका सरलीकृत दृश्य प्रस्तुत किया। "डेबिट एक बैंक खाता जिसमें 10 लाइन जावा प्रोग्राम है" उदाहरण हमेशा विशेष रूप से कष्टप्रद थे क्योंकि मैंने इस सरल कार्य के वास्तविक जीवन उदाहरणों को COBOL कोड की 6000 लाइनों (और जावा रिप्लेसमेंट प्रयास 3500 लाइनों तक चलने से पहले छोड़ दिया था। जैसा कि अक्षम्य है!)।

शुक्र है कि OO पुस्तकें अब वास्तविक जीवन की जटिलताओं को स्वीकार करती हैं, और, उनसे निपटने के तरीके के उपयोगी उदाहरण प्रदान करती हैं।

लेकिन अगर आप यह देखना चाहते हैं कि कोड फंक्शनल प्रोग्रामिंग की केवल 15 पंक्तियों में बैंक खाता कैसे चलाया जाए तो वह आपका आदमी है