हम वास्तव में ऑब्जेक्ट-ओरिएंटेड प्रोग्रामिंग का उपयोग कब करते हैं? [बन्द है]

Question

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

मुझे पता है कि ऑब्जेक्ट-ओरिएंटेड कोड डेफिनिशन क्लीनर द्वारा नहीं है, और इसके विपरीत नॉन-ओओ कोड परिभाषा गंदे द्वारा नहीं है। मैं जो सवाल पूछ रहा हूं वह कम या ज्यादा राय-आधारित हो सकता है लेकिन कुछ नियम हो सकते हैं जिनके बारे में मुझे जानकारी नहीं है।

क्या किया जाना है इसके बारे में कुछ और जानकारी:

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

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

तो, मेरा सवाल यह होगा कि आप लोग कैसे जानते हैं / निर्णय लेते हैं कि एक आवेदन में ओओपी का उपयोग कब करना है ?

Comments

पुन:, "ग्राहक ... कोड के बारे में परवाह नहीं करता है, वह बस काम करना चाहता है।" ठीक है, फिर बात करते हैं। लेकिन यह बात कितनी जटिल है? आप वास्तव में आवश्यकताओं को कितनी अच्छी तरह समझते हैं? यह कितनी संभावना है कि ग्राहक कुछ समय बाद आपसे बात बदलने के लिए कहेगा? कभी-कभी एक त्वरित और गंदी हैक आपको सभी की आवश्यकता होती है, लेकिन जितना अधिक समय और ऊर्जा आप इसमें निवेश करने जा रहे हैं, उतनी अधिक संभावना है कि समस्या को हल करने के लिए कुछ संरचित दृष्टिकोण (जैसे, ओओ डिजाइन) आपको लाभान्वित करेंगे।

— सोलोमन स्लो

अपनी पोस्ट में "EDIT" या अन्य समान मोनिकर्स का उपयोग न करें। प्रत्येक स्टैक एक्सचेंज पोस्ट में एक विस्तृत संपादन इतिहास होता है, जिसे कोई भी समीक्षा कर सकता है। "मैं OOP क्या था" जैसी जानकारी किसी भी तरह से टिप्पणी में अधिक उपयुक्त है, न कि आपके प्रश्न पर।

— रॉबर्ट हार्वे

@RobertHarvey ठीक है, मिल गया। मैं अगली बार यह करूँगा।

— ग्रेजेडेनु एलेक्स।

Answer 1

पायथन एक बहु-प्रतिमान भाषा है जिसका अर्थ है कि आप कार्य के लिए सबसे उपयुक्त प्रतिमान चुन सकते हैं। जावा जैसी कुछ भाषाएँ एकल प्रतिमान OO हैं जिसका अर्थ है कि यदि आप किसी अन्य प्रतिमान का उपयोग करने का प्रयास करते हैं तो आपको सिरदर्द होगा। "हमेशा OO का उपयोग करें" वाले पोस्टर संभवतः ऐसी भाषा में पृष्ठभूमि से आ रहे हैं। लेकिन सौभाग्य से आपके पास एक विकल्प है!

मैं ध्यान देता हूं कि आपका प्रोग्राम एक CLI ऐप है, जो कुछ इनपुट (csv और config files) को पढ़ता है और कुछ आउटपुट (xml फाइलें) तैयार करता है, लेकिन इंटरेक्टिव नहीं है और इसलिए इसमें एक स्टेटफुल GUI या API नहीं है। इस तरह के कार्यक्रम को स्वाभाविक रूप से इनपुट से आउटपुट तक एक फ़ंक्शन के रूप में व्यक्त किया जाता है, जो उप-कार्यों के लिए अन्य कार्यों को सौंपता है।

दूसरी ओर OO उत्परिवर्तनीय अवस्था को घेरने के बारे में है और इसलिए यह इंटरैक्टिव अनुप्रयोगों, जीयूआई और एपीआई की उत्परिवर्तनीय स्थिति के लिए अधिक उपयुक्त है। यह कोई संयोग नहीं है कि OO को पहले GUI के समानांतर विकसित किया गया था।

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

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

नीचे पंक्ति: मैं संगठन के लिए मॉड्यूल में विभाजित कार्यों का एक गुच्छा सुझाता हूं, लेकिन कोई वस्तु नहीं।

Comments

अंत में एक अच्छी तरह से संतुलित उत्तर जो केवल OOP :-)

— cmaster

इस तरह के जवाब की मुझे उम्मीद थी। क्या आपके उत्तर का थोड़ा विस्तार कर सकता है? यह अब तक का कमाल लग रहा है।

— ग्रेजेडेनु एलेक्स।

@ डेक्सटर: आपकी तुलना में। आप किस तरह की अतिरिक्त जानकारी चाहते हैं?

— जैक्सबी जुएल

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

— एंड्रयू

@ बर्गी: हाँ, यह एक बहु-प्रतिमान भाषा का लाभ है। आप अपने स्वयं के कार्यक्रम को ओओ-शैली में लिखने के बिना ओओ पुस्तकालयों का उपयोग कर सकते हैं।

— जैक्सबीस

Answer 2

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

जीओआई से निपटने के लिए ओओपी एक शानदार उपकरण है, और अन्य स्थितियों में जहां सिस्टम के कुछ हिस्सों में अस्थिरता होती है।

अन्य स्थितियां, जैसे कि आप जो वर्णन करते हैं, जहां डेटा स्रोत से पढ़ा जाता है, संसाधित और गंतव्य के लिए लिखा गया है, एक अलग दृष्टिकोण द्वारा अच्छी तरह से नियंत्रित किया जाता है: घोषणात्मक (या फ़ंक्शन) प्रोग्रामिंग। डेटा प्रोसेसिंग के लिए डिक्लेरेटिव कोड OOP समाधानों की तुलना में पढ़ने में आसान और कम दोनों हो जाता है।

जिस तरह एक हथौड़ा और देखा दोनों शक्तिशाली उपकरण हैं जब सही तरीके से उपयोग किया जाता है, तो भी ऑब्जेक्ट-ओरिएंटेड और डिक्लेक्टिव प्रोग्रामिंग तकनीक हैं। आप शायद एक आरे के हैंडल से लकड़ी के टुकड़े में कील ठोक सकते थे। इसी तरह, आप एक हथौड़ा के साथ लकड़ी का एक टुकड़ा आधा में तोड़ सकते हैं। इसी तरह, आप केवल कार्यों के साथ एक GUI बना सकते हैं और वस्तुओं के साथ डेटा संसाधित कर सकते हैं। जब उपकरण सही तरीके से उपयोग किए जाते हैं, तो परिणाम क्लीनर और सरल होते हैं।

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

Answer 3

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग आपके शस्त्रागार में चार नए उपकरण जोड़ता है :

1. encapsulation
2. मतिहीनता
3. विरासत
4. बहुरूपता

आप अपने आवेदन में OOP का उपयोग करेंगे जब यह इन साधनों से लाभ के लिए पर्याप्त रूप से पर्याप्त और जटिल हो गया है।

Comments

अमूर्तता और बहुरूपता प्रोग्रामिंग के कई "झुकाव" द्वारा प्रदान किए गए उपकरण हैं। OOP वास्तव में अन्य दृष्टिकोणों की तुलना में इनकैप्सुलेशन का एक कमजोर रूप प्रदान करता है क्योंकि वंशानुक्रम लीक के अमूर्त डिजाइनों को प्रोत्साहित करता है। टूलकिट में ओओपी वास्तव में एकमात्र चीज है विरासत में मिला है, जिसे व्यापक रूप से एक बुरी चीज के रूप में देखा जाता है।

— डेविड अर्नो

@ दाविदनो: आप मूल रूप से कह रहे हैं "कभी ओओपी का उपयोग न करें।"

— रॉबर्ट हार्वे

यह अन्य लोगों के कोड को देखते हुए काम करने की कोशिश के दिन से पीछे है, एक कार्यक्रम के सीधे आगे की प्रक्रियात्मक कार्यान्वयन अक्सर ओओ डिजाइन की खराब समझ के साथ कार्यान्वयन से बेहतर होता है। ओओ आर्किटेक्चर बहुत शक्तिशाली हो सकता है लेकिन खाना पकाने में मसाले की तरह इस्तेमाल किया जाना चाहिए, विशेषज्ञ ज्ञान और सिर्फ सही मात्रा में। एक खराब रेस्‍टोरेंट में केचप मांगने के बारे में OO डिजाइन का दुरुपयोग आम है।

— फिल

चार उपकरणों में से कोई भी (एनकैप्सुलेशन, एब्स्ट्रक्शन, इनहेरिटेंस, पॉलिमोर्फिज्म) ओओपी के लिए विशिष्ट है। शायद आपको यह बताना चाहिए कि ओओपी अन्य आयामों से इन आयामों से कैसे भिन्न है।

— जियोर्जियो

@gardenhead श्रेष्ठता की आपकी विषम भावना आपकी स्थिति के लिए कुछ नहीं कर रही है। शायद आपको एक सवाल का शीर्षक देना चाहिए कि 'सबसे अधिक रोजगार देने वाली भाषा अक्सर OO क्यों होती है?' बेहतर अभी तक, Ctrl + F और 'GUI' टाइप करें।

— गूसडर

Answer 4

यह सवाल मुझे थोड़ा उलझा हुआ लगता है। यदि आप इसे पायथन में लिख रहे हैं, तो आप निश्चित रूप से जा रहे हैं वस्तुओं उपयोग हैं । जब आप कोई फ़ाइल खोलते हैं, तो यह एक ऑब्जेक्ट लौटाता है। जब आप परिणाम प्राप्त करते हैं, तो यह एक पुनरावृत्ति वस्तु देता है। आपके द्वारा बनाया गया प्रत्येक फ़ंक्शन एक ऑब्जेक्ट है। पायथन अनुप्रयोगों में OO के मूल्य पर सवाल उठाना कम से कम कहना अजीब लगता है।

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

शायद OO डिजाइन और कार्यात्मक डिजाइन के आसपास ये अंतर अप्रचलित हो रहे हैं। यदि मैं एक OO डिज़ाइन किए गए ऑब्जेक्ट * पर एक पॉलीमॉर्फिक फ़ंक्शन बनाता हूं और कार्यात्मक रूप से स्टाइल फ़ंक्शन * के पैरामीटर के रूप में ऑब्जेक्ट पर उस फ़ंक्शन के लिए एक पॉइंटर पास करता है, तो क्या यह ओओ है या यह कार्यात्मक है? मुझे लगता है कि यह दोनों और समस्याओं को हल करने के लिए एक बहुत प्रभावी तरीका है।

मुझे लगता है कि असली सवाल यह है कि 'आपको अपने स्वयं के वर्गों को डिज़ाइन करना शुरू कर देना चाहिए? मुझे लगता है कि इसके लिए सही उत्तर है: जब यह समाधान को सरल बनाने में मदद करता है। मैं किसी भी वस्तु उन्मुख भाषा के लिए एक ही मूल उत्तर देना चाहूंगा।

* अतिरेक जानबूझकर किया गया है: मैं नहीं चाहता कि यहां आरोप लगाया जाए कि वस्तुएं OO हैं या यह कार्य कार्यात्मक हैं।

Comments

हाँ, ऑब्जेक्ट OOP के बराबर नहीं हैं। एक ऑब्जेक्ट होने और ऑब्जेक्ट्स और उनके इंटरैक्शन के आसपास अपने आर्किटेक्चर को संरचित करने के बीच एक अंतर है। अगर आप एक फ़ंक्शन बनाते हैं, तो इसका मतलब यह नहीं है कि आप कार्यात्मक प्रोग्रामिंग कैसे कर रहे हैं।

— सारा

आप काफी आसानी से एक पायथन / जावास्क्रिप्ट ऑब्जेक्ट को रिकॉर्ड मान सकते हैं, जो काफी कार्यात्मक है। कार्यात्मक भाषाओं में वस्तुएं हैं। कुंजी दूसरे शब्द में है: केंद्रित। OOP भाषाएं पूरी तरह से वस्तुओं का उपयोग करने के आसपास केंद्रित हैं, जबकि कुछ अन्य भाषाएं उन्हें केवल आपके टूलबॉक्स के दूसरे भाग के रूप में लगती हैं।

— डैन पेंट्री

Answer 5

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के बारे में सबसे बड़ी बात यह है कि प्रोग्राम फ्लो के बारे में तर्क करने के बजाय आप राज्य के बारे में तर्क देना शुरू करते हैं।

बहुत बार मैं ऑब्जेक्ट देखता हूं, मैं विधियों को देखता हूं लेकिन मैं जो भी देखता हूं वह यह है कि कोड के पीछे ड्राइविंग सोचा राज्य के बजाय प्रवाह है।

और एक बार जब आप राज्य के बारे में तर्क देते हैं तो अच्छा OOP कोड बनाना आसान होता है क्योंकि जैसे ही आपका कोड बहुत जटिल हो जाता है आप ध्यान देते हैं कि आप अपने राज्य के बारे में और कारण नहीं जान सकते हैं और आपको रिफ्लेक्टर की आवश्यकता है।

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

और अच्छी बात यह है कि आप इसके लिए परीक्षण कर सकते हैं।

Comments

डिस्क से फ़ाइल पढ़ने के साथ आपका उदाहरण बनाम वेब से एक फ़ाइल पढ़ने को विभिन्न कार्यों के साथ भी लागू किया जा सकता है। उसके लिए आपको OO की आवश्यकता नहीं है।

— जैक्सबी

Answer 6

आम आदमी की शर्तों में:

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

कहा, खाते में लेने के लिए अन्य कारक हैं:

• क्या आपके प्रोग्रामर OOP / OOD में कुशल हैं?
• क्या आपके प्रोग्रामर एक ओओपी भाषा में कुशल हैं?
• क्या आपको लगता है कि सॉफ्टवेयर समय के साथ जटिल हो जाएगा?
• क्या आप भविष्य में कोड को स्केल या पुन: उपयोग करने की योजना बना रहे हैं?
• क्या आपको लगता है कि आपका "डिज़ाइन" एक संपत्ति बन सकता है? यानी क्या आप इसे आगे बढ़ने या भविष्य की परियोजनाओं के लिए एक आधार के रूप में लाभ उठा पाएंगे?

मुझे गलत मत समझो: आप OOP का उपयोग किए बिना वह सब हासिल कर सकते हैं लेकिन OOP के साथ यह आसान हो जाएगा।

परंतु...

यदि आपकी टीम OOP / OOD में पारंगत नहीं है और उस क्षेत्र में कोई विशेषज्ञता नहीं है, तो आपके पास मौजूद संसाधनों के साथ जाएं।

Answer 7

तो, मेरा सवाल यह होगा कि आप लोग कैसे जानते हैं / निर्णय लेते हैं कि एक आवेदन में ओओपी का उपयोग कब करना है?

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

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

• लॉगिंग, एक उदाहरण के रूप में, क्योंकि यह एक अलग लकड़हारे को स्थानापन्न करना आसान बनाता है

• प्रोग्राम संरचना के बड़े टुकड़े, क्योंकि आप कई समवर्ती लोगों को जोड़ते हैं, और शायद मल्टी सीपीयू प्रोसेसर का लाभ उठाते हैं। उदाहरण के लिए, एक वेब सर्वर वस्तुओं के कारण कई समवर्ती अनुरोध हैंडलर का उपयोग कर सकता है।

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

Comments

मैंने डाउनवोट नहीं किया (भले ही मैं इसके करीब था), लेकिन मुझे लगता है कि यह आपके द्वारा प्राप्त डाउनवोट्स का कारण है: "हमेशा इसका उपयोग करें, क्योंकि यह बहुत अच्छा है" शायद ही कभी एक अच्छी सलाह है। हमेशा अपवाद होते हैं। कोई उपकरण बिना डाउनसाइड के नहीं आता है, और OOP कोई अपवाद नहीं है। लोगों को बताएं कि यह अच्छा है, लोगों को बताएं कि यह किस लिए अच्छा है, लोगों को बताएं कि यह क्यों अच्छा है, लोगों को बताएं कि यदि वे कर सकते हैं तो विकल्पों से बचें, लेकिन कभी भी लोगों को विकल्पों के बारे में नहीं सोचने के लिए कहें।

— 16

@cmaster, मैं ठीक हूं अगर लोग नीचे हैं, यह उनकी पसंद है, और मैंने भी किया है। विषय वस्तु पर, मुझे अभी भी लगता है कि यह सवाल पूछने वाले व्यक्ति के लिए सही उत्तर है; IMHO, ओपी को ओओपी का उपयोग करने के बजाय ओओपी का उपयोग करने का निर्णय लेने की कोशिश करने के लिए और कभी-कभी एक वर्ग बनाने के लिए चुनना होगा, लेकिन अन्यथा प्रक्रियात्मक कोड लिखने के लिए ओपी को सभी तरह से कूदने की जरूरत है।

— एरिक इद्दत

@cmaster मैं एरिक की सलाह की सराहना कर सकता हूं। जितनी बार "यह निर्भर करता है" इस तरह का उत्तर राजनीतिक रूप से जाने का सही तरीका हो सकता है, चलो इसे लोगों का सामना करें, OO बहुत ही प्रोग्रामिंग वातावरण के लिए आधार रेखा बन गया है जो इसका समर्थन करते हैं। तो चलो अपने आप को बच्चा नहीं है, आप शायद ही OO के साथ गलत कर सकते हैं। वर्णित स्क्रिप्ट, हालांकि रेखीय, जटिल है जो वस्तुओं के लिए आपको कुछ लाभ लाने के लिए पर्याप्त है।

— मार्टिन माट

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

— आज्ञाकारी

के रूप में आसान के रूप में यह "अभी तक एक और नासमझ OOP zealot" के रूप में दूर लहर है, मुझे लगता है कि वास्तव में आंतरिक और इसे अवशोषित करने के लिए कुछ में वास्तव में 100% जाने के लिए कुछ कहा जाना है। ऐसा नहीं है कि आप इसे अपने जीवन के बाकी हिस्सों के लिए हर दिन उपयोग कर सकते हैं, लेकिन इसलिए आप वास्तव में ताकत और कमजोरियों को छोड़ देते हैं और न केवल उनके बारे में पढ़ते हैं। मैं कट्टर OOP और कुछ महीने कट्टर FP (á la haskell) और कुछ महीने प्रक्रियात्मक C और इतने पर जाने वाले कुछ महीने बिताने के बारे में किसी को भी सलाह दूंगा। बस वहाँ जाओ और नीचे उतरो और उसके साथ गंदा करो।

— सारा

Answer 8

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

कैसे करें - यह आपके कोड का फ्रेम वर्क पार्ट है, जहां आप किसी प्रकार का एब्सट्रैक्शन बनाते हैं, यह तय करते हैं कि आपके ब्लॉक सामान्य रूप से कैसे काम करते हैं और यह अन्य ब्लॉक के साथ कैसे इंटरैक्ट करता है।

क्या - यह हिस्सा वह है जहां ब्लॉक वास्तविक काम खुद करते हैं। यहाँ वर्ग को आधार वर्ग से बनाया गया है जो "सेक्शन में कैसे करें" में बनाते हैं।

एक OOPS से बहुत फायदा हो सकता है

1. यदि आप किसी मौजूदा ढांचे का पुन: उपयोग कर सकते हैं और केवल "क्या करें" अनुभाग में विशिष्ट विवरणों को लागू करना है।
2. वर्तमान परियोजना के लिए जो कार्यक्षमता कार्यान्वित की जा रही है, वह सामान्य / आमतौर पर उपयोग की जाने वाली एक और अन्य परियोजना है / भविष्य की परियोजनाएं वर्तमान परियोजना के विकास के दौरान बनाई गई रूपरेखा से लाभ प्राप्त कर सकती हैं।
3. एक बड़ी समस्या को हल करने के लिए आम तौर पर जाने जाने वाली विशाल परियोजनाओं को तोड़ना।
4. छोटे प्रोजेक्ट के लिए OOPS का उपयोग करें और इसे इस्तेमाल करने की आदत डालें और तैयार रहें जब 1 - 3 प्रकार की समस्या आती है

Comments

तो आप मूल रूप से कह रहे हैं कि आपको हमेशा ओओपी का उपयोग करना चाहिए , चाहे जिस वास्तविक कार्य को आप हल करना चाहते हैं?

— जैक्सबी जुएल

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

— राहुल मेनन