सॉफ्टवेयर जटिलता के प्रबंधन में OOP की प्रभावशीलता पर अध्ययन किया गया है? [बन्द है]


14

ओओपी को अक्सर सॉफ्टवेयर में जटिलता के प्रबंधन की एक प्रभावी रणनीति के रूप में माना जाता है, गैर-ओओपी प्रक्रियात्मक प्रोग्रामिंग के विपरीत।

क्या इस धारणा का कोई अध्ययन किया गया है? क्या यह साबित होता है कि OOP अक्सर बड़ी परियोजनाओं में जटिलता का प्रबंधन करने में मदद करता है?


4
बहुत दिलचस्प होने के बावजूद, आईएमएचओ, प्रतिमानों की "जटिलता" और "प्रभावकारिता" को मापना एक कठिन और पूर्वाग्रहपूर्ण प्रयास है। प्रत्येक कार्यक्रम अद्वितीय है, प्रत्येक डेवलपर अद्वितीय है, और इसकी तुलना करना कठिन है। इसके अलावा, उत्पादकता एक प्रतिमान से अधिक लेकिन उपकरण, पारिस्थितिकी तंत्र, शिक्षण सामग्री पर निर्भर करती है। एक निष्पक्ष अध्ययन से पूरे छात्र समूहों को या तो भाषा के साथ समान आवश्यकताओं को प्रोग्राम करने देना चाहिए और परिणाम देखना चाहिए। हालांकि, यहां तक ​​कि उन्हें पूर्व ज्ञान होने की संभावना है कि यह पक्षपाती है। मुझे इस तरह के किसी अध्ययन का पता नहीं है।
डेगनेलिस

पढ़ाई नहीं, लेकिन कुछ अकादमिक शेख़ी: en.wikipedia.org/wiki/Object-oriented_programming#Criticism
Den

1
यह एक मुश्किल सवाल है क्योंकि OOP के रूप में उद्योग में अभ्यास अत्यधिक अत्यावश्यक हो जाता है। इसलिए हम ऐसी प्रक्रियाओं से चले गए हैं जो ग्लोबल्स को उन तरीकों से छूती हैं जो उन वस्तुओं को संशोधित करती हैं जो अन्य वस्तुओं को संशोधित करती हैं जो अन्य वस्तुओं को संशोधित करती हैं; साइड इफेक्ट्स कुछ अधिक स्पष्ट हैं, लेकिन अभी भी बहुत सारी कार्रवाई चल रही है। दूसरी तरफ जब आप साइड इफेक्ट्स को कम करते हैं और चीजों को अपरिवर्तनीय बनाते हैं तो कुछ लोग यह तर्क देंगे कि आप कार्यात्मक प्रोग्रामिंग कर रहे हैं।
डोभाल

2
इसे सही मायने में मापने का कोई तरीका नहीं है- यह एक क्वांटम प्रभाव है जहां इसे मापने से परिणाम प्रभावित होता है।
डेडएमजी जूल 15'14

1
तुलना करने के लिए, किसी के पास एक वैकल्पिक प्रतिमान होना चाहिए जो बहुत बड़ी प्रोग्रामिंग प्रणालियों पर लागू होता है, जो सामान्य कौशल के प्रोग्रामर द्वारा निर्मित होता है (अर्थात विशेषज्ञों या अत्याधुनिक शिक्षाविदों की टीम द्वारा नहीं)। बड़े सिस्टम में नेटवर्किंग, डेटाबेस, लोड-बैलेंसिंग और अतिरेक (यानी अविश्वसनीय मशीनें), अन्य चीजों के साथ शामिल होते हैं। प्रोग्रामिंग भाषा के प्रतिमानों के लिए हो सकने वाली किसी भी बहस में मुद्दों की बाद वाली सूची हावी है।
रॉन्ग

जवाबों:


10

मुझे मात्रात्मक माप के साथ किसी भी अध्ययन की जानकारी नहीं है। जैसा कि दूसरों ने आपके प्रश्न की टिप्पणियों में उल्लेख किया है, इसे प्राप्त करना व्यावहारिक रूप से असंभव है। हालाँकि कुछ दार्शनिक पत्र हैं जो इसका उत्तर देने का प्रयास करते हैं।

उस विषय पर मेरा पसंदीदा पेपर बेन मोसले और पीटर मार्क्स द्वारा टार पिट से बाहर है । यह जटिल सिस्टम डिज़ाइन के बारे में सम्मानजनक स्रोतों से विभिन्न बयानों के कारण काफी दिलचस्प परिणाम देता है।

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


5

हाँ कुछ अध्ययन हुए हैं। यहाँ एक है: http://www.csm.ornl.gov/~v8q/Homepage/Papers%20Old/spetep-%20printable.pdf

मूल रूप से यह निष्कर्ष निकाला है कि प्रक्रियात्मक कोड उत्पादकता और OO भाषा उत्पादकता के बीच एक औसत दर्जे का अंतर नहीं है .... लेकिन सच्चाई यह है कि, इस प्रकार के प्रश्न इतने संदर्भ संवेदनशील हैं, कोई भी अध्ययन आपको यह बताने वाला नहीं है कि आपको किसी दिए गए स्थिति में क्या करना चाहिए। ।


लंबे समय तक ऐसे अध्ययन हुए जिन्होंने दिखाया कि डेस्कटॉप कंप्यूटरों को कार्यालय के वातावरण में पेश करने से उत्पादकता में वृद्धि नहीं हुई।

@nocomprende क्या आपके पास उन अध्ययनों को गलत निष्कर्ष मानने का कोई कारण है? 1989 में औसत ऑफिस कर्मी द्वारा उपयोग किया गया 1989 का पीसी एक आधुनिक मशीन द्वारा इस्तेमाल की जाने वाली आधुनिक मशीन से पूरी तरह से अलग है। इसी तरह, वस्तु प्रौद्योगिकी के अनुप्रयोग में समय के साथ सुधार हो भी सकता है और नहीं भी।
जोर्जेन फॉग

1
@ JørgenFogh मुझे लगता है कि मैं इस कथन से सहमत था कि अध्ययन हमेशा यह नहीं दिखाता है कि सामान्य ज्ञान क्या है। व्यवसायों ने कार्यालयों में कंप्यूटर का उपयोग करना शुरू नहीं किया होता अगर वे चीजों को बदतर बनाते। अगर यह मदद नहीं करता तो लोग OO दृष्टिकोण विकसित करने में दशकों नहीं बिताते। वे करेंगे? ठीक है, लोग गलत हो सकते हैं, लेकिन आप इसे एक या दूसरे तरीके से कैसे साबित कर सकते हैं? यह क्या है: "क्या यह आपके लिए काम करता है ?"
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.