ऑब्जेक्ट ओरिएंटेड भाषा में नॉन-ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग [बंद]

Question

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

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

पुनश्च: मैं यहाँ प्रक्रियात्मक प्रोग्रामिंग पर ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के गुण बताने के लिए नहीं कह रहा हूँ।

Comments

आवश्यकतानुसार विभिन्न तकनीकों को लागू करने से बचने का कोई कारण नहीं है। आप प्रोग्रामर को केस के आधार पर किसी मुकदमे के पक्ष और विपक्ष को तौलने की आवश्यकता होगी। अक्सर यह व्यक्तिगत शैली के लिए नीचे आता है।

— चोसपंडियन

मैं कभी नहीं यह एक मुद्दा हो गया है। टीम और / या अन्य वास्तुकला को देखते हुए भाषा हमेशा एक निर्धारित उपकरण थी।

के संभावित डुप्लिकेट क्या प्रक्रियात्मक प्रोग्रामिंग से अधिक ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग के लाभ क्या है?

— Doc Brown

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

— डॉक ब्राउन

एक विशेषता जोड़ें जो आपके द्वारा दर्ज किए गए सूत्र को प्रदर्शित करता है और फिर एक वर्गमूल फ़ंक्शन जोड़ें (ऐसा पहले न करें, जो धोखा होगा।) और हमें बताएं कि आप क्या सोचते हैं।

— जेएफओ

Answer 1

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

मुश्किल हिस्सा उस समय को याद नहीं करना है जब आपके कार्यक्रम की जटिलता उस आकार तक पहुंच जाती है जो अधिक संरचना की मांग करती है। अन्यथा आप स्पेगेटी कोड के एक विशाल ढेर के साथ समाप्त हो जाएंगे।

Comments

यदि सरल "व्यायाम" कार्यक्रम विकसित करना शुरू हो जाता है, तो सबसे अच्छा तरीका इसे इस तरह से लागू करना है कि इसे बाद में फिर से फैक्टर किया जा सके। साझा करने के लिए धन्यवाद :) :)

— FaizanRabbani

@ कार्लस्मिथ: बिल्कुल। लेकिन जब मैंने अपना उत्तर लिखा, तो मैंने वास्तविक प्रश्न के बिंदुओं और पैमाने पर ध्यान देने की कोशिश की।

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

Answer 2

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

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

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

एक कार्यात्मक शैली के विपरीत ऑब्जेक्ट-ओरिएंटेड शैली पर स्विच करने का एक बड़ा हिस्सा यह है कि तब-तब बयान "रन इस एक्शन" स्टेटमेंट में परिवर्तित हो रहा है। यदि तत्कालीन वक्तव्यों के एक विशाल सेट के बजाय, आप कोड को इसकी कार्रवाई चलाने के लिए कहते हैं। वास्तव में कौन सी कार्रवाई चल रही है यह आपके द्वारा आपूर्ति किए गए कार्यान्वयन पर निर्भर करता है।

उदाहरण के लिए, यहाँ C # -स्टाइल छद्मकोड में कार्यात्मक शैली है:

if ( action == "email" ) { 
    callEmailFunction(userInfo);
}
else if ( action == "sms" ) { 
    callSmsFunction(userInfo);
}
else if ( action == "web" ) { 
    endpoint = "http://127.0.0.1/confirm";
    confirmWeb(endpoint, userinfo);
} 
...

लेकिन हो सकता है कि आप इसे फिर से लिख सकें:

interface IConfirmable {
    void Confirm(UserInfo userinfo);
}

public class ConfirmEmail : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmSms : IConfirmable { 
    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via email
    }
}

public class ConfirmWeb : IConfirmable { 
    // this is a constructor
    public ConfirmWeb(string endpoint) { 
        ...
    }

    public void Confirm(UserInfo userinfo) {
        // do the appropriate thing to confirm via web
    }
} 

और फिर कोड ही:

// An implementation that decides which implementation of the base class to use
// This replaces the if-then statements in the functional programmming.
IConfirmable confirmer = ConfirmerFactory.GetConfirmer();

// get the userinfo however you get it, 
// which would be the same way you get it in the functional example.
UserInfo userinfo = ...;

// perform the action.
confirmer.Confirm(userinfo);

अब, अगर इफ-इन के अंदर बहुत कम कोड है, तो यह बिना किसी लाभ के बहुत काम की तरह दिखता है। और जब-अगर-तब में बहुत कम कोड होता है, तो यह सही है: यह कोड के लिए बहुत काम है जो समझना मुश्किल है।

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

Comments

विस्तृत विश्लेषण के लिए +1। :) इस पर मेरे कुछ विचार हैं।

— फैजानरब्बानी

एक तरफ: कृपया हर उत्तर पर "धन्यवाद" टिप्पणी पोस्ट करना बंद करें। हम सिर्फ सवालों और जवाबों पर ध्यान देना पसंद करते हैं, चर्चा पर नहीं।

— फिलिप केंडल

यह उदाहरण कार्यात्मक की तुलना में अधिक आवश्यक है।

— ऑरेंजडॉग

सी एफ श्रृंखला के- जिम्मेदारी पैटर्न ।

— एरिक

बस एक नोट, यदि आप if / else के एक झुंड की ओर झुक रहे हैं या स्टेटमेंट स्विच करते हैं, तो यह हमेशा किसी प्रकार के लुकअप टेबल पर विचार करने का विकल्प होता है। तो फिर से लिखने का एक और तरीका जो var dict = new Dictionary<string,Action<UserInfo>{ { "email", callEmailFunction }, { "sms", callSmsFunction } }; dict[ action ]( userInfo );( की तर्ज पर स्थिर हो सकता है, त्रुटि से निपटने में

— चूक हुआ

Answer 3

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

Comments

"इसका मतलब यह नहीं है कि यदि आप गैर ओओपी दृष्टिकोण का उपयोग करते हैं तो आप कभी भी अपनी परियोजना को अपग्रेड नहीं कर सकते हैं लेकिन फिर यह एक थकाऊ काम होगा।": ओओपी आपकी परियोजना का विस्तार करने में मदद करता है जब अधिकांश एक्सटेंशन में नई कक्षाएं शामिल होती हैं (जैसे नए विजेट जोड़ना) एक GUI)। जब अधिकांश एक्सटेंशन में नए ऑपरेशन को जोड़ना शामिल होता है, तो एक प्रक्रियात्मक डिजाइन अधिक प्रभावी हो सकता है।

— जियोर्जियो

कब से "पुरानी शैली" नामक "ऑब्जेक्ट ओरिएंटेड" नहीं है?

— डेनियलस्क