ऑब्जेक्ट ओरिएंटेशन और एल्गोरिदम के बीच संबंध

Question

जैसा कि मैंने कुछ एल्गोरिदम पाठ्यपुस्तकों को पढ़ा है, वे कुछ समस्याओं (छंटाई, कम से कम पथ) या कुछ सामान्य तरीकों (पुनरावर्ती एल्गोरिदम, विभाजित और जीत, गतिशील प्रोग्रामिंग ...) के लिए चतुर प्रक्रियाओं से भरे हैं। मैं वहाँ वस्तु उन्मुख प्रोग्रामिंग के कुछ निशान पाया; (वे अधिक प्रक्रिया-उन्मुख क्यों हैं?)।

तब मैं सोच रहा था:

• एल्गोरिदम और OOP के बीच क्या संबंध है? क्या वे दो स्वतंत्र विषय हैं?
• क्या कुछ समस्याएं हैं जो केवल OOP द्वारा प्रस्तुत और हल की जा सकती हैं?
• ओओपी एल्गोरिदम की मदद कैसे कर सकता है? या यह किस दिशा में इसे प्रभावित कर सकता है?

Comments

कोई डुप्लिकेट नहीं है, लेकिन संबंधित प्रोग्रामर

— डॉक्टर ब्राउन

@DocBrown धन्यवाद, यह बहुत मददगार था, हालाँकि यहाँ हम OO के आसपास कुछ अवधारणाओं पर विचार कर सकते हैं जैसे वंशानुक्रम, बहुरूपता ...

— अहमद

"एल्गोरिदम पाठ्यपुस्तक अधिक प्रक्रिया-उन्मुख क्यों हैं?" जावा प्रक्रिया-उन्मुख भी है। जावा एक वस्तु उन्मुख प्रक्रियात्मक भाषा है।

— पीटर बी

के संभावित डुप्लिकेट कितना महत्वपूर्ण अध्ययन कर रही है एल्गोरिदम और सिद्धांत के लिए एक महान प्रोग्रामर बनने के लिए है?

— gnat

@ याट ने मेरे प्रश्न को संशोधित किया, पता नहीं कि क्या वे स्पष्टीकरण आवश्यक थे या अच्छे थे या नहीं। हालाँकि, मैं डॉक्टर ब्राउन द्वारा संबोधित प्रश्न को अधिक उत्तर देता हूं जो मेरी चिंताओं से संबंधित हैं।

— अहमद

Answer 1

सबसे पहले, हम OOP द्वारा क्या मतलब है परिभाषित करते हैं। OOP से मेरा मतलब मुख्य रूप से है:

• विवरण और कक्षा में विवरणों को छिपाना।
• विरासत और आभासी तरीकों के माध्यम से व्यवहार की बहुरूपता।

अब, आपके प्रश्न का उत्तर देने के लिए:

एल्गोरिदम और OOP के बीच क्या संबंध है? क्या वे दो स्वतंत्र विषय हैं?

हाँ।

वहाँ कुछ समस्या है जो केवल प्रस्तुत किया और OOP द्वारा हल किया जा सकता है?

सं OOP प्राथमिक प्रस्तावों सुविधा और प्रोग्रामर के लिए कोड के बारे में कारण करने की क्षमता। यह आपकी अभिव्यंजक शक्ति को नहीं बढ़ाता है।

ओओपी एल्गोरिदम की मदद कैसे कर सकता है? या यह किस दिशा में इसे प्रभावित कर सकता है?

जैसा मैंने ऊपर कहा। दोनों बिंदुओं को मैंने OOP के रूप में वर्णित किया है जो यहां लागू होते हैं। एल्गोरिदम और उनके डेटा संरचनाओं के विवरण को छिपाने में सक्षम होने के कारण पूरी बात के बारे में कारण पता चल सकता है। कई एल्गोरिदम विवरण आपको लगता है कि एल्गोरिथ्म के साथ चारों ओर खिलवाड़ के उपयोगकर्ता नहीं करना चाहती होते हैं। उन विवरणों को छिपाने से बहुत मदद मिलती है।

बहुरूपी व्यवहार करने की क्षमता भी महान है। List/ निकालें जोड़ें / संग्रह में कहीं भी आइटम साफ करने में सक्षम होने के रूप में परिभाषित किया गया है। लेकिन इसे रिसाइसेबल ऐरे, डबल-लिंक्ड या सिंगल-लिंक्ड आदि के रूप में लागू किया जा सकता है, कई कार्यान्वयन के लिए एकल एपीआई होने से पुन: उपयोग में मदद मिल सकती है।

एल्गोरिदम टेक्स्टबुक अधिक प्रक्रिया-उन्मुख क्यों हैं?

जैसा कि मैंने कहा, एक एल्गोरिथ्म को लागू करने के लिए OOP आवश्यक नहीं है। इसके अलावा, कई एल्गोरिदम पुराने और निर्मित हैं जब ओओपी अभी भी व्यापक नहीं था। तो यह एक ऐतिहासिक बात भी हो सकती है।

Comments

ग्रंथों साल की उम्र के बावजूद, आप शायद OOP के साथ एक एल्गोरिथ्म का गंदा पानी नहीं करना चाहते, सिर्फ इसलिए कि यह आधुनिक है।

— गुस्सोर

Answer 2

एल्गोरिदम और OOP दो अलग-अलग मामले है, जो केवल आम में है कि वे कर रहे हैं सीएस -नियम। सीधे शब्दों में - एक एल्गोरिथ्म एक की तरह है , खाना पकाने नुस्खा: करने के लिए एक्स आपको निम्न की आवश्यकता सामग्री और कदम 1,2,3,4,5,6 करना ... तो आप अपने भोजन तैयार किया है।

जैसा कि कहा गया, ऐसा लगता है एक प्राकृतिक algortihms के लिए फिट एक में वर्णित है प्रक्रियात्मक रास्ता। प्रक्रियात्मक साधन कुछ भी नहीं के अलावा अन्य: पहला ऐसा एक्स और उसके बाद करना y ।

एक आम समस्या है: » एक्स के सेट को कैसे सॉर्ट करना है ?«। समाधान समझने में आसान है bubble-sort:

1. अंतिम तत्व से सेट पर इरेट करें जब तक आप पहले तत्व तक नहीं पहुँच गए और पुनरावृत्ति करते समय
2. पहली यात्रा की वर्तमान तत्व के लिए शुरू से ही एक 2 यात्रा शुरू करें और
3. इसके उत्तराधिकारी के साथ (2) के वर्तमान तत्व की तुलना करें
4. अधिक से अधिक, स्वैप पदों हैं

यह एल्गोरिथम का एल्गोरिथम / मौखिक विवरण है bubblesort।

यहाँ एक प्रक्रियात्मक / छद्मकोड कार्यान्वयन आता है

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

वह तो आसान था।

वह OOP से कैसे संबंधित है ? आप इस एल्गोरिथ्म का उपयोग वस्तुओं के संग्रह (एक वस्तु स्वयं) के इलाज के लिए कर सकते हैं :

जावास्क्रिप्ट में उदाहरण (हालांकि कोई साफ OO-लिंगो , लेकिन कोई बॉयलरप्लेट के पास और आसान समझने के लिए के साथ)

objects =[{"name":"Peter"}, {"name":"Paul"}, {"name":"Mary"}]

compareObjects=function(x,y){ return x.name>y.name };

sorted = objects.sort(compareObjects)

console.log(sorted)

हमारे पास एक संग्रह है objects, बी) इस संग्रह के लिए एक विधि सामान्य है sortजिसमें छंटाई एल्गोरिथ्म दूर / सार शामिल है और ग) हमारी वस्तुओं पीटर , पॉल और मैरी । छँटाई के लिए विनिर्देश यहाँ पाया गया है ।

एल्गोरिदम और OOP के बीच क्या संबंध है? क्या वे दो स्वतंत्र विषय हैं?

से क्या कहा गया था, यह स्पष्ट होना चाहिए, इस सवाल का जवाब होना चाहिए: हाँ, वे independend हैं।

ओओपी एल्गोरिदम की मदद कैसे कर सकता है? या यह किस दिशा में इसे प्रभावित कर सकता है?

OOP सिर्फ एक प्रोग्रामिंग शैली है। यह किसी भी तरह की मदद नहीं कर सकता है । अन्यथा वस्तुओं को कुछ करने के लिए एक ओओ भाषा में एक एल्गोरिथ्म लागू किया जा सकता है (जैसा कि दिखाया गया है)

वहाँ कुछ समस्या है जो केवल प्रस्तुत किया और OOP द्वारा हल किया जा सकता है?

मैं एक के बारे में नहीं सोच सकता (लेकिन इसका मतलब यह नहीं है, कि यह असंभव है)। लेकिन अगर आप इसे दूसरे तरीके से देखते हैं: ओओपी उपयोगी है, यदि आप कुछ समस्याओं को मॉडल करना चाहते हैं और एक उपयुक्त एल्गोरिथ्म के साथ ith को हल करना चाहते हैं। आप का रिकॉर्ड कहो friendsआप उन्हें मॉडल सकता है objectsके साथ propertiesऔर अगर आप एक चाहते हैं listके friends अनुसार क्रमबद्ध किसी भी तरह से, आप उदाहरण-कोड के ऊपर बिल्कुल ऐसा करने के लिए दिया इस्तेमाल कर सकते हैं।

एल्गोरिदम टेक्स्टबुक अधिक प्रक्रिया-उन्मुख क्यों हैं?

जैसा कि कहा गया है: यह अधिक स्वाभाविक है , क्योंकि प्रक्रियात्मक एल्गोरिदम का चरित्र है।

Comments

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

— डोभाल

मुझे लगता है, यह बिल्कुल सही नहीं है। जब कार्यात्मक प्रोग्रामिंग भाषाओं की बात की जाती है, तो आप कार्यान्वयन के बारे में बात कर रहे हैं , एल्गोरिथ्म के बारे में नहीं। उदाहरण के लिए Haskell के quicksort wiki.haskell.org/Introduction#Quicksort_in_Haskell को लें, तो हम दोनों सहमत होंगे, कि यह quicksort-algortihm के लिए एक कार्यात्मक कार्यान्वयन है। लेकिन यदि आप वर्णन करते हैं , तो क्या किया जाता है, तो आपको विवरण के एक अद्भुत मोड में वापस आना होगा । और इस विवरण से, आप एक प्रक्रियात्मक कार्यान्वयन लागू कर सकते हैं।

— थॉमस जं।

@ थोमसजंक आपको विवरण के एक प्रक्रियात्मक मोड में वापस नहीं आना है, क्योंकि एक कार्यात्मक कार्यान्वयन कहता है कि चीजें क्या हैं , चरणों का अनुक्रम नहीं। आप शुद्ध और आलसी अभिकलन के लिए एक क्रमिक विवरण कैसे देंगे? आप समय से पहले नहीं जानते कि अभिव्यक्ति का कितना मूल्यांकन किया जाएगा, और न ही किस क्रम में इसके उप-भावों की गणना की जाएगी।

— डोभाल

दुर्भाग्य से मेरे पास कोई सीएस डिग्री नहीं है, इसलिए मुझे निम्नलिखित सिद्ध करने के लिए एक व्यापक कौशल की कमी है: लेकिन मुझे लगता है, प्रत्येक एल्गोरिथ्म को एक तरह से या दूसरे तरीके से वर्णित किया जा सकता है। कोई वास्तविक शुद्ध कार्यात्मक एल्गोरिथ्म नहीं है। क्या ऐसा नहीं है, परिणाम में पूर्णता का क्या मतलब है?

— थॉमस जोड़

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

— AK_

Answer 3

आपको कोई समस्या है।

व्यवसाय डोमेन मॉडल आपकी समस्या का वर्णन करता है, और समस्या डोमेन से अवधारणाओं आप के साथ काम कर सकता है जा रहे हैं।

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

प्रतिमान प्रोग्रामिंग है कि क्या OOP,, कार्यात्मक तार्किक, प्रक्रियात्मक, या यहाँ तक कि गैर-संरचित, का वर्णन कैसे आप अपने समाधान है, जो प्रपत्र इसे ले जा रहा है, जो "सॉफ्टवेयर इंजीनियरिंग" अवधारणाओं आप करते हैं काम लिए जा रहे हैं की संरचना करने के लिए जा रहे हैं, और जो " प्रोग्रामिंग थ्योरी "अवधारणाओं को आप नियोजित करने जा रहे हैं।

इसे और अधिक बस, एल्गोरिदम सामान्य रूप में समस्या के लिए अपने समाधान का वर्णन कहें ( "यह मैं क्या करने जा रहा हूँ है")। अपने वास्तविक क्रियान्वयन के साथ प्रतिमान सौदों प्रोग्रामिंग है ( "यह कैसे मैं यह करने के लिए जा रहा हूँ है")।

Comments

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

— एंड्रेस एफ।

Answer 4

एल्गोरिदम = " कैसे " कहानी बताएं (यानी वांछित परिणाम उत्पन्न करने के लिए समय में डेटा संरचनाओं का उपयोग करके इनपुट डेटा में हेरफेर कैसे करें)

OOP = एक " कार्यप्रणाली " जो OO- भाषाओं द्वारा प्रोग्राम (= एल्गोरिथम + डेटा संरचना) लिखने की सुविधा प्रदान करती है जो आपको स्मृति सुरक्षा और अमूर्तता प्रदान करती है

OOP एल्गोरिदम को लागू करने का एक प्रतिमान मात्र है।

अच्छा सादृश्य : फिल्में

आप स्टंटमैन को रोजगार देकर दृश्य रिकॉर्ड कर सकते हैं या नहीं। स्क्रीनप्ले (एल्गोरिथ्म) नहीं बदलता है। लोगों को अंतिम परिणाम में कोई अंतर नहीं देखना चाहिए।

संपादित करें: आप एक अच्छी गुणवत्ता की कोशिश कर सकते हैं एमओओसी: https://www.coursera.org/course/algs4partI जो चर्चा किए गए विषयों (विशेष रूप से ओओपी दृष्टिकोण) को मिलाता है और जो आप यहां पूछते हैं उसका सार देता है।

Comments

मैंने वास्तव में आपकी फिल्म सादृश्य का आनंद लिया। मैं भविष्य में वह उधार लेता रहूंगा।

— मार्क लाफलेर

Answer 5

Alexander Stepanov सी ++ मानक टेम्पलेट लायब्रेरी, (एसटीएल) है, जो सी के लिए मूलभूत एल्गोरिथ्म पुस्तकालय ++ है के मूल निर्माता है। C ++ एक बहु-प्रतिमान भाषा है जिसमें "ऑब्जेक्ट ओरिएंटेड" विशेषताएं शामिल हैं, लेकिन अलेक्जेंडर स्टेपानोव के पास ऑब्जेक्ट ओरिएंटेशन के बारे में कहने के लिए यह है:

http://www.stlport.org/resources/StepanovUSA.html

STL ऑब्जेक्ट ओरिएंटेड नहीं है। मुझे लगता है कि आर्टिफिशियल इंटेलिजेंस के रूप में ऑब्जेक्ट ओरिएंटेशन लगभग एक धोखा है। मुझे अभी तक एक दिलचस्प कोड कोड देखना है जो इन OO लोगों से आता है।

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

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

स्टेपानोव ने अपनी एल्गोरिथ्म लाइब्रेरी को वस्तुओं के साथ नहीं, बल्कि जेनेरिक इटरेटर्स के साथ व्यक्त किया ।

Comments

वैसे वह गलत है ... ज्यादातर इसलिए कि STL बहुत ज्यादा ऑब्जेक्ट ओरिएंटेड है ... टर्म के बाद से ज्यादा मॉडर्न में ऑब्जेक्ट ओरिएंटेड ...

— AK_

@AK_ - मुझे नहीं लगता कि वह बिल्कुल गलत है। एसटीएल भी लगभग OO शब्द का कोई अर्थ में नहीं है। आप एसटीएल का सीधे अनुवाद एक गैर-ओओ भाषा में कर सकते हैं जिसमें पैरामीट्रिक बहुरूपता (जैसे हास्केल या एसएमएल) है जो इसे किसी भी पर्याप्त तरीके से बदलने की आवश्यकता के बिना है।

— जूल्स 7

Answer 6

एल्गोरिदम से बताएं कि कंप्यूटर क्या करना चाहिए। संरचना का वर्णन है कि एल्गोरिथ्म कैसे रखा गया है [स्रोत कोड में]। OOP प्रोग्रामिंग की एक शैली है जो कुछ "ऑब्जेक्ट ओरिएंटेड" संरचनाओं का लाभ उठाती है।

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

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

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

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

क्या कुछ समस्याएं हैं जो केवल OOP द्वारा प्रस्तुत और हल की जा सकती हैं?

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

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

यह यह नहीं कहता है कि हम भविष्य में कुछ मज़ेदार नए ढांचे के लिए ओओपी का परित्याग नहीं करेंगे। यह केवल कहता है कि यह हमारे टूलबॉक्स में सबसे प्रभावी उपकरणों में से एक है जो आज आश्चर्यजनक रूप से बड़े पैमाने पर प्रोग्रामिंग कार्यों के लिए है। भविष्य की समस्याएं हमें विभिन्न संरचनाओं का उपयोग करके विकास का दृष्टिकोण करने का कारण बन सकती हैं। एक के लिए, मुझे उम्मीद है कि तंत्रिका जाल को बहुत अलग विकास दृष्टिकोण की आवश्यकता होती है, जो "ऑब्जेक्ट ओरिएंटेड" हो सकता है या नहीं।

एल्गोरिथ्म डिजाइनरों के सोचने के तरीके से मुझे निकट भविष्य में ओओपी का प्रसार नहीं दिखता है। आज तक, सामान्य पैटर्न यह है कि कोई व्यक्ति एक एल्गोरिथ्म डिज़ाइन करता है जो OOP का लाभ नहीं उठाता है। OOP समुदाय को पता चलता है कि एल्गोरिथ्म वास्तव में OOP संरचना में फिट नहीं है, और वास्तव में इसकी आवश्यकता नहीं है, इसलिए वे पूरे एल्गोरिथ्म को OOP संरचना में लपेटते हैं और इसका उपयोग करना शुरू करते हैं। विचार करें boost::shared_ptr। रेफरेंस काउंटिंग एल्गोरिदम जो अंदर आराम करते shared_ptrहैं वे बहुत ओओपी फ्रेंडली नहीं हैं। हालाँकि, यह पैटर्न तब तक लोकप्रिय नहीं हुआ जब तक shared_ptrकि इसके चारों ओर एक OOP आवरण नहीं बना जो एक OOP संरचित प्रारूप में एल्गोरिदम की क्षमताओं को उजागर करता। अब, यह इतना लोकप्रिय है कि इसने इसे C ++, C ++ 11 के लिए नवीनतम युक्ति बना दिया।

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

Answer 7

महान उत्तरों के अलावा, मैं OOP और एल्गोरिथम के बीच एक अतिरिक्त वैचारिक समानता का उल्लेख करूंगा ।

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

सामान्य तौर पर, यह कंप्यूटर विज्ञान के सभी क्षेत्रों में मानक अभ्यास है; हालाँकि, इस मार्गदर्शक सिद्धांत का परिणाम OOP में एक विकासवादी पथ है जो इसे OOP वातावरण में एल्गोरिदम को लागू करने के लिए पारस्परिक रूप से लाभप्रद बनाता है।

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

एक एल्गोरिथ्म एक संगणना प्रदर्शन करने के लिए उपयोग किए जाने वाले चरणों का कार्यान्वयन है, एक वह जो पूर्व शर्त ले जाएगा और पोस्टकंडिशन का उत्पादन करेगा।

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

OOP में एल्गोरिदम लागू करने से, एक इन छोटे चरणों विनिमेय बना सकते हैं।

अंत में, कि एफपी और OOP परस्पर अनन्य नहीं हैं को ध्यान में रखना। ऊपर वर्णित कुछ भी एफपी के समान ही लागू हो सकता है।

Comments

बिंदु के लिए धन्यवाद! जैसा कि आपने कहा था कि अगर एल्गोरिथ्म सिर्फ कुछ कदम है, तो OOP हमें और अधिक अमूर्त कदम प्रदान करने में मदद कर सकता है। आपने "OOP में एल्गोरिदम को लागू करने" के बारे में बताया, मैंने यह पूछने के लिए अपने प्रश्न को संशोधित किया कि क्या यह हमेशा फायदेमंद है?

— अहमद

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

— AK_

@AK_ मैं सहमत हूं कि अनुबंध द्वारा डिजाइन मेरे जवाब में वर्णित समानता के लिए सही नाम है। मैं जो दावा कर रहा हूं वह यह है कि OOP एक डिजाइन प्रतिमान के रूप में अनुबंध द्वारा डिजाइन को दृढ़ता से गले लगाता है - बस किसी भी OOP पाठ्यपुस्तक को पढ़ें। मेरे मूल उत्तर में यह भी उल्लेख है कि यह समानता OOP के लिए अनन्य नहीं है।

— 16

Answer 8

What is the relation between algorithms and OOP? Are they two independent topics?

एल्गोरिदम के बारे में कर रहे हैं कि कैसे हल करने के लिए एक समस्या (कैसे दिए गए इनपुट से उत्पादन उत्पन्न करने के लिए), OOP के बारे में है कैसे तैयार या व्यक्त करने के लिए हमारे समाधान (एल्गोरिथ्म के कदम)।

एक एल्गोरिथ्म को प्राकृतिक भाषा या असेंबली भाषा में वर्णित किया जा सकता है, लेकिन हमारे पास एक प्राकृतिक भाषा में जो अवधारणाएँ हैं, वे हमें इसे बेहतर ढंग से लिखने और समझने में मदद करती हैं। उदाहरण के लिए बबल-सॉर्ट के लिए एल्गोरिथ्म हो सकता है:

bubbleSort(Array A)
  for (n=A.size; n>1; n=n-1){
    for (i=0; i<n-1; i=i+1){
      if (A[i] > A[i+1]){
        A.swap(i, i+1)
    } 
  } 
}

के विवरण को छिपाने के लिए swapऔर इसे संबंधित करने के लिए Aहमने एक OOP सिंटैक्स और सुविधा का उपयोग किया, फिर OO एल्गोरिथम को हमारी प्राकृतिक भाषा और समझ के करीब बनाता है।

Are there some problems which can only be presented and solved by OOP?

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

How OOP can help algorithms? Or in which direction it can affect it?

यह एल्गोरिथ्म को आसान या अधिक समझने या समझने या बनाने में मदद कर सकता है। यह विवरण छिपा सकता है और समाधान की एक बड़ी तस्वीर प्रदान कर सकता है।

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

इस संबंध में, OOP कंप्यूटर पर हमारे एल्गोरिथ्म के कार्यान्वयन, परीक्षण और शोधन की सुविधा प्रदान करता है और इसे हमारी प्राकृतिक भाषा के पास एक भाषा में कंप्यूटर के लिए लिखता है।