चूंकि मैंने ऑब्जेक्ट उन्मुख प्रोग्रामिंग का अध्ययन शुरू किया है, इसलिए मैं अक्सर लेख/ब्लॉग पढ़ता हूं कि कहानियां बेहतर हैं, या सभी समस्याओं को वस्तुओं के रूप में मॉडल नहीं किया जाना चाहिए। आपके व्यक्तिगत प्रोग्रामिंग रोमांच से, आपको लगता है कि ओओपी द्वारा एक समस्या बेहतर हल हो जाती है?ओओपी कब बेहतर है?
कोई कठोर नियम नहीं है। जब आप समस्याओं को हल करने और ओओ मानसिकता में सोचने में बेहतर होते हैं तो ओओपी के साथ एक समस्या बेहतर हल हो जाती है। ऑब्जेक्ट ओरिएंटेशन सिर्फ एक और उपकरण है जो समस्याओं को हल करने के लिए एक बेहतर उपकरण कंप्यूटिंग करने की कोशिश कर रहा है।
हालांकि, यह बेहतर कोड पुन: उपयोग करने की अनुमति दे सकता है, और यह भी निएटर कोड का कारण बन सकता है। लेकिन अक्सर इन अत्यधिक प्रशंसनीय गुणों में, वास्तविक वास्तविक मूल्य के संबंध में हैं। मौजूदा कार्यात्मक अनुप्रयोग में ओओ तकनीकों को लागू करने से वास्तव में बहुत सारी समस्याएं हो सकती हैं। कौशल कई अलग-अलग तकनीकों को सीखने और हाथ में समस्या के लिए सबसे उचित लागू करने में निहित है।
OO अक्सर सॉफ्टवेयर विकास, जहां कई बार यह हाथ में इस मुद्दे को लागू किया जा करने के लिए उपयुक्त नहीं है का हल की तरह एक निर्वाण के रूप में उद्धृत किया गया है। यह अक्सर, सही समाधान तक पहुंचने के लिए किसी समस्या की अतिवृद्धि का कारण बन सकता है, जब अक्सर यह वास्तव में आवश्यक नहीं होता है।
संक्षेप में, OOP वास्तव में उन्मुखी है नहीं ऑब्जेक्ट प्रोग्रामिंग, लेकिन मानचित्रण वस्तु एक प्रोग्रामिंग OO तकनीक समर्थन करने में सक्षम भाषा के लिए सोच रही थी उन्मुखी। ओओ तकनीकों को उन भाषाओं द्वारा समर्थित किया जा सकता है जो स्वाभाविक रूप से ओओ नहीं हैं, और ऐसी तकनीकें हैं जिनका उपयोग आप लाभकारी लाभों के लिए कार्यात्मक भाषाओं के भीतर कर सकते हैं।
उदाहरण के तौर पर, मैं अब लगभग 20 वर्षों के लिए ओओ सॉफ्टवेयर विकसित कर रहा हूं, इसलिए जब मैं लिख रहा हूं, तो मैं समस्याओं को हल करते समय ओओ शर्तों में सोचता हूं। वर्तमान में मैं पर्ल 5.6 का उपयोग करके बहुरूपता लागू कर रहा हूं, जो इसका समर्थन नहीं करता है। मैं इस रूप में यह कोड के रखरखाव और विस्तार बल्कि एक विकास के मुद्दे की तुलना में एक सरल विन्यास कार्य कर देगा, ऐसा करने के लिए चुना है।
सुनिश्चित नहीं हैं कि अगर यह स्पष्ट है।ओओ अदालत में कड़ी मेहनत करने वाले लोग हैं, और ऐसे लोग हैं जो कार्यात्मक अदालत में कठिन हैं। और फिर ऐसे लोग हैं जिन्होंने दोनों की कोशिश की है और प्रत्येक से सर्वश्रेष्ठ लेने का प्रयास किया है। न तो सही है, लेकिन दोनों के पास कुछ बहुत अच्छे गुण हैं जिनका उपयोग आप भाषा का कोई फर्क नहीं पड़ता।
यदि आप ओओपी सीखने की कोशिश कर रहे हैं, तो ओओपी पर ध्यान केंद्रित न करें, लेकिन ऑब्जेक्ट ओरिएंटेड विश्लेषण और सामान्य ओओ सिद्धांतों को समस्या समाधान के पूरे स्पेक्ट्रम में उपयोग करने का प्रयास करें।
मुझे लगता है कि यह उन राज्यों पर राज्य और संबंधित कार्रवाइयों के साथ कुछ संयोजक मॉडलिंग करते समय सबसे अच्छा फिट बैठता है। मुझे लगता है कि यह अस्पष्ट है, लेकिन मुझे यकीन नहीं है कि यहां एक सही जवाब है।
ओओपी के बारे में बात यह है कि यह आपको एक बड़ी प्रणाली बनाने में वास्तविक वरदान है, जो आपको डेटा और जानकारी को दूर कर देता है। आप अन्य प्रतिमानों के साथ भी ऐसा ही कर सकते हैं, लेकिन ऐसा लगता है कि ओओपी इस श्रेणी में विशेष रूप से सहायक है।
यह भी उस भाषा पर निर्भर करता है जिसका आप उपयोग कर रहे हैं। यदि यह समृद्ध ओओपी समर्थन वाली भाषा है, तो आपको शायद इसका लाभ अपने लाभ के लिए उपयोग करना चाहिए। यदि ऐसा नहीं होता है, तो आपको समस्या को छोटे, आसानी से टेस्ट करने योग्य टुकड़ों में तोड़ने में मदद के लिए अन्य तंत्र ढूंढने की आवश्यकता हो सकती है।
मुझे ओओपी को बेचा गया है।
जब भी आप किसी समस्या के लिए अवधारणा को परिभाषित कर सकते हैं, तो शायद इसे किसी ऑब्जेक्ट में लपेटा जा सकता है।
ओओपी के साथ समस्या यह है कि कुछ लोगों ने इसका अधिक उपयोग किया और अपना कोड समझने के लिए और भी मुश्किल बना दिया। यदि आप वस्तुओं में जो कुछ डालते हैं और जो आपने सेवाओं (स्थिर कक्षाओं) में रखा है, उसके बारे में सावधान हैं, तो आपको ऑब्जेक्ट्स का उपयोग करने से फायदा होगा।
बस ऐसी चीज़ न डालें जो ऑब्जेक्ट में किसी ऑब्जेक्ट से संबंधित न हो क्योंकि आपको अपनी ऑब्जेक्ट को कुछ नया करने की आवश्यकता है जिसे आपने प्रारंभ में, रिफैक्टर और उस कार्यक्षमता को जोड़ने का सबसे अच्छा तरीका नहीं सोचा था।
कुछ स्थानों जहां ओओ इतना अच्छा नहीं है, जहां आप एसक्यूएल जैसे डेटा के "सेट्स" से निपट रहे हैं। ओओ सेट आधारित संचालन को और अधिक कठिन बनाता है क्योंकि यह वास्तव में दो सेटों या दो सेटों के सुपरसेट को छेड़छाड़ करने के लिए डिज़ाइन नहीं किया गया है। ,
पर विचार करें उदाहरण के लिए, एक कार्यक्रम डेटा का एक अलग रूप में एक XML दस्तावेज़ कन्वर्ट करने के लिए लिख रहे हैं:
इसके अलावा, कई बार जब एक कार्यात्मक दृष्टिकोण इस तरह के इस उदाहरण MSDN से लिया के रूप में अधिक समझ बनाने चाहते हैं । हालांकि यह निश्चित रूप से एक सी # प्रोग्राम लिखना संभव होगा जो एक्सएमएल दस्तावेज के माध्यम से विश्लेषण किया गया था और दस्तावेज में विभिन्न बिंदुओं पर क्या कदम उठाने के लिए विभिन्न बयानों को लागू किया गया था, एक तर्कसंगत बेहतर दृष्टिकोण परिवर्तन को एक एक्स्टेंसिबल स्टाइलशीट के रूप में लिखना है भाषा परिवर्तन (एक्सएसएलटी) कार्यक्रम। आश्चर्य की बात नहीं है, एक्सएसएलटी के अंदर कार्यात्मकता की एक बड़ी लकीर है
मुझे लगता है कि यह 'चीजों' के संदर्भ में किसी दिए गए समस्या के बारे में सोचने में मदद करता है।
यदि समस्या को एक या अधिक 'चीजें' होने के बारे में सोचा जा सकता है, जहां प्रत्येक 'चीज़' में कई गुण या जानकारी के टुकड़े होते हैं जो इसके राज्य को संदर्भित करते हैं, और कई संचालन जो पर किए जा सकते हैं यह - तो ओओपी शायद जाने का रास्ता है!
मैं एक पुराना टाइमर हूं, लेकिन लंबे समय से ओओपी प्रोग्राम भी किया है। मैं इसका उपयोग करने के लिए ओओपी का उपयोग करने के खिलाफ व्यक्तिगत रूप से हूं। मैं वस्तुओं को मौजूदा के लिए विशिष्ट कारणों को प्राथमिकता देता हूं, कि वे कुछ ठोस बनाते हैं, और वे समझ में आते हैं।
मेरे पास बहुत से नए डेवलपर्स के साथ समस्या यह है कि उनके पास संसाधनों की कोई अवधारणा नहीं है जो वे बनाए गए कोड के साथ उपभोग कर रहे हैं। बड़ी मात्रा में डेटा से निपटने और डेटाबेस तक पहुंचने पर प्रदर्शन और संसाधनों के लिए "सही" ऑब्जेक्ट मॉडल सबसे खराब चीज हो सकती है।
मेरी निचली पंक्ति यह है कि यदि यह किसी ऑब्जेक्ट के रूप में समझ में आता है तो इसे किसी ऑब्जेक्ट के रूप में प्रोग्राम करें, जब तक कि आप अपने ऑब्जेक्ट मॉडल के कार्यान्वयन के प्रदर्शन/संसाधन प्रभाव पर विचार न करें।
ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग सीखने की कुंजी डिजाइन पैटर्न के बारे में सीख रही है। डिज़ाइन पैटर्न के बारे में सीखकर आप कक्षाओं की आवश्यकता होने पर बेहतर होते हैं और जब वे नहीं होते हैं। कक्षाओं और ओओपी भाषाओं की अन्य विशेषताओं के उपयोग में प्रोग्रामिंग में इस्तेमाल की जाने वाली किसी भी चीज़ की तरह आपके डिजाइन और आवश्यकताओं पर निर्भर करता है। एल्गोरिदम की तरह डिजाइन पैटर्न एक उच्च स्तरीय अवधारणा हैं।
एक डिजाइन पैटर्न पारंपरिक प्रोग्रामिंग भाषाओं के लिए एल्गोरिदम की समान भूमिका निभाता है। एक डिज़ाइन पैटर्न आपको बताता है कि ऑब्जेक्ट को कुछ उपयोगी कार्य करने के लिए कैसे बनाएं और संयोजित करें। सर्वोत्तम एल्गोरिदम की तरह सर्वश्रेष्ठ डिजाइन पैटर्न सामान्य सामान्य समस्याओं के लिए आवेदन करने के लिए सामान्य हैं।
आईएमएचओ ओओपी का उपयोग करने वाले अधिकांश लोग डिजाइन पैटर को बहुत लंबे समय तक (या कभी नहीं) तक नहीं सीखते हैं ... शायद डिजाइन पैटर्न ओओपी के अच्छे उपयोगों को चित्रित करते हैं लेकिन निश्चित रूप से कुंजी नहीं - * समझ * एनकैप्यूलेशन के सिद्धांत, पॉलिमॉर्फिज्म और विरासत सार – Gishu
प्रक्रियात्मक कार्यक्रमों के लिए एल्गोरिदम उपयोगी काम करने के लिए अलग-अलग बयान और कार्यों को एक साथ कैसे रखा जाए, सीखने के लिए महत्वपूर्ण हैं। डिजाइन पैटर्न ओओपी के लिए एक ही भूमिका निभाते हैं। प्रोग्रामिंग के संबंधित तरीकों के बारे में सीखने के लिए एल्गोरिदम और डिज़ाइन पैटर्न सीखना सबसे महत्वपूर्ण बात है। –
मेरी राय में यह एक व्यक्ति के रूप में आपके बारे में अधिक प्रश्न है। कुछ लोग कार्यात्मक शर्तों में बेहतर सोचते हैं और अन्य कक्षाएं और वस्तुओं को पसंद करते हैं। मैं कहूंगा कि ओओपी बेहतर है जब यह दुनिया के आपके आंतरिक (व्यक्तिपरक) मानसिक मॉडल से मेल खाता है।
यह समस्या से निर्भर करता है: ओओपी प्रतिमान उपयोगकर्ता के कार्यों (उदाहरण: वेब अनुप्रयोग) के दौरान रहने वाली बहुत सारी इकाई के साथ विचलित सिस्टम या ढांचे को डिजाइन करने में उपयोगी होता है।
लेकिन यदि आपके पास गणित की समस्या है तो आप एक कार्यात्मक भाषा (LISP) पसंद करेंगे; एक प्रदर्शन-महत्वपूर्ण प्रणालियों के लिए आप एडीए या सी, आदि का उपयोग करेंगे।
भाषा ओओपी उपयोगी है क्योंकि यह प्रोग्राम के चलाने में कचरा कलेक्टर (स्मृति का स्वचालित उपयोग) का भी उपयोग करता है: आप सी में प्रोग्राम करते हैं मैन्युअल रूप से स्मृति की समस्या को मैन्युअल रूप से डिबग और सही करना होगा।
ऑब्जेक्ट उन्मुख कोड और प्रक्रियात्मक कोड में अलग-अलग विस्तारशीलता बिंदु हैं। ऑब्जेक्ट ओरिएंटेड समाधान मौजूदा कार्यों को संशोधित किए बिना नए वर्गों को जोड़ना आसान बनाता है (ओपन-क्लोज़ेड सिद्धांत देखें), जबकि प्रक्रियात्मक कोड आपको मौजूदा डेटा संरचनाओं को संशोधित किए बिना कार्यों को जोड़ने की अनुमति देता है। सिस्टम के काफी अलग-अलग हिस्सों में अपेक्षित परिवर्तन के प्रकार के आधार पर अलग-अलग दृष्टिकोण की आवश्यकता होती है।
ओओपी उपयोगी है जब आपके पास चीजें हैं। एक सॉकेट, एक बटन, एक फ़ाइल। यदि आप एर में कक्षा समाप्त करते हैं तो यह लगभग हमेशा एक ऐसा कार्य होता है जो कक्षा होने का नाटक करता है। टेस्टरुनर संभवतः एक ऐसा फ़ंक्शन होना चाहिए जो परीक्षण चलाता है (और शायद रन परीक्षण नाम)।
5 मानदंड हैं कि क्या आपको ऑब्जेक्ट आधारित, कार्यात्मक या प्रक्रियात्मक कोड पर ऑब्जेक्ट ओरिएंटेड का पक्ष लेना चाहिए। याद रखें कि ये सभी शैलियों सभी भाषाओं में उपलब्ध हैं, वे शैलियों हैं। ये सभी एक शैली में लिखे गए हैं "क्या मुझे इस स्थिति में ओओ का पक्ष लेना चाहिए?"
सिस्टम बहुत जटिल है और लगभग 9 के एलओसी (बस एक मनमाना स्तर) से अधिक है। - जैसे-जैसे सिस्टम अधिक जटिल हो जाते हैं, जटिलता को समाहित करके प्राप्त लाभ काफी थोड़ा ऊपर जाते हैं। ओओ के साथ, अन्य तकनीकों के विपरीत, आप अधिक से अधिक जटिलता को समाहित करते हैं, जो इस स्तर पर बहुत मूल्यवान है। ऑब्जेक्ट आधारित या प्रक्रियात्मक इस से पहले अनुकूल होना चाहिए। (यह किसी विशेष भाषा के दिमाग की वकालत नहीं कर रहा है। OO C मेरे दिमाग में ओओ सी ++ से अधिक इन सुविधाओं को फिट करता है, एक ऐसी भाषा जो लीकी अबास्ट्रक्शन के लिए कुख्यात प्रतिष्ठा है और दोपहर के भोजन के लिए भी 1 मध्यम/बाधा प्रोग्रामर के साथ दुकानों की खाने की क्षमता है)।
आपका कोड डेटा (यानी डेटाबेस आधारित या गणित/विश्लेषण आधारित) पर संचालन नहीं है। डाटाबेस आधारित कोड अक्सर प्रक्रियात्मक शैली के माध्यम से अधिक आसानी से प्रतिनिधित्व किया जाता है। विश्लेषण आधारित कोड अक्सर एक कार्यात्मक शैली में प्रतिनिधित्व किया जाता है।
आपका मॉडल कुछ का सिमुलेशन है (ओओ सिमुलेशन पर एक्सेल)।
आप ऐसा कुछ कर रहे हैं जिसके लिए ओओ का ऑब्जेक्ट आधारित उपप्रकार प्रेषण मूल्यवान है (उर्फ, आपको किसी निश्चित प्रकार और विभिन्न उपप्रकारों की सभी वस्तुओं को एक संदेश भेजने की आवश्यकता है और एक उचित, लेकिन अलग, प्रतिक्रिया प्राप्त करें उन सभी को)।
आपका ऐप बहु-थ्रेडेड नहीं है, खासकर एक गैर-कार्यकर्ता कार्य विधि कोड कोड के प्रकार में। ओओ उन कार्यक्रमों में काफी समस्याग्रस्त है जो बहुप्रचारित हैं और विभिन्न कार्यों को करने के लिए विभिन्न धागे की आवश्यकता होती है। यदि आपका प्रोग्राम एक या दो मुख्य थ्रेडों के साथ संरचित है और कई कार्यकर्ता धागे एक ही काम कर रहे हैं, तो ओओ प्रोग्रामों के गड़बड़ नियंत्रण प्रवाह को संभालना आसान है, क्योंकि सभी कार्यकर्ता धागे जो स्पर्श करते हैं उन्हें अलग किया जाएगा और उन्हें माना जा सकता है कोड का एक monolithic खंड। वास्तव में किसी भी अन्य प्रतिमान पर विचार करें। मल्टीथ्रेडिंग (साइड इफेक्ट्स की कमी एक बड़ा वरदान है) पर कार्यात्मक एक्सेल, और ऑब्जेक्ट आधारित प्रोग्रामिंग आपको ओओ के कुछ encapsulation के साथ वरदान दे सकता है, हालांकि आपके कोडबेस के महत्वपूर्ण वर्गों में अधिक ट्रेस करने योग्य प्रक्रिया कोड के साथ। इस क्षेत्र में पाठ्यक्रम की उत्कृष्टता भी उत्कृष्ट है।
व्यक्तिगत रूप से, मुझे लगता है कि ओओपी किसी भी बड़े आवेदन के लिए व्यावहारिक रूप से एक आवश्यकता है। मैं ओओपी का उपयोग किए बिना कोड की 100k लाइनों से अधिक प्रोग्राम रखने की कल्पना नहीं कर सकता, यह एक रखरखाव और डिजाइन दुःस्वप्न होगा।
मैं आपको बताता हूं कि ओओपी खराब है।
जब वास्तुकार वास्तव में जटिल, गैर-दस्तावेज ओओपी कोड लिखता है। परियोजना के माध्यम से आधा रास्ता छोड़ देता है। और विभिन्न परियोजनाओं में उनके कई सामान्य कोड टुकड़ों में इस्तेमाल होने वाले कोड में गायब कोड हैं। .NET परावर्तक के लिए भगवान का शुक्र है।
और संगठन विजुअल सोर्स सेफ या सबवर्जन नहीं चला रहा था।
और मुझे खेद है। लॉग इन करने के लिए कोड के 2 पेजों को हास्यास्पद है, भले ही यह कटा हुआ है ....
ओओ किसी ऑब्जेक्ट से संबंधित तर्क को एक ही स्थान (कक्षा, या ऑब्जेक्ट) में रखने के लिए अनुमति देता है ताकि यह हो सके decoupled और डीबग और बनाए रखने के लिए आसान है।
मैंने जो देखा है, यह है कि प्रत्येक ऐप ओओ और प्रक्रियात्मक कोड का संयोजन है, जहां प्रक्रियात्मक कोड गोंद है जो आपके सभी ऑब्जेक्ट्स को एक साथ जोड़ता है (कम से कम, आपके मुख्य फ़ंक्शन में कोड)। जितना अधिक आप अपने प्रक्रियात्मक कोड को ओओ में बदल सकते हैं, उतना ही आसान होगा कि यह योर कोड बनाए रखे।
क्यों OOP प्रोग्रामिंग के लिए प्रयोग किया जाता है:
क्यों 5.6 आदमी perl? और मुझे पूरा यकीन है कि पर्ल बहुरूपता कर सकता है, कम से कम मुझे लगता है कि ऑब्जेक्ट ओरिएंटेड पर्ल पुस्तक इसका वर्णन करती है। पर्ल ओओ वास्तव में शक्तिशाली है, अगर वास्तव में बदसूरत और barebones। – xenoterracide
पर्ल 5.6 क्योंकि वह कंपनियों के बुनियादी ढांचे थे। उस समय इसे अपडेट करने के लिए बड़ी संख्या में सर्वरों और संपूर्ण समर्थन आधारभूत संरचना में भारी परिवर्तन शामिल होगा। हालांकि, 2 साल बाद यह सब बदल गया है। – Xetius