प्रक्रियात्मक कोड बनाम OOP कोड

Question

मैंने 13000+ लाइनों के PHP में एक प्रक्रिया को प्रोसेडुरल स्टाइल में पूरा किया है [क्योंकि मैं इससे बहुत परिचित हूं, हालांकि मुझे OOP पता है], और यह परियोजना पूरी तरह से चल रही है।

लेकिन क्या मुझे इसे OOP में बदलना चाहिए? [ क्योंकि दुनिया OOP के साथ व्यस्त है ]

मेरे कोड को OOP [इनकैप्सुलेशन, इनहेरिटेंस मूल रूप से ...] की किसी भी सुविधा की आवश्यकता नहीं है!

तो मुझे क्या करना चाहिए?

और अगर मैं इसे OOP में बदल दूं तो मुझे किस तरह की मदद मिलेगी?

Comments

यदि आपको इस परियोजना को बदलना है तो कृपया हमें सूचित रखें। यह जानना दिलचस्प होगा कि क्या आपको खुशी है कि आपने यह निर्णय लिया है या पछतावा है।

— जेएफओ

आपको इनकैप्सुलेशन की आवश्यकता है। OO इसे प्राप्त करने का एक तरीका है; शायद आपके पास एक और है जो आपके लिए काम करता है, लेकिन एक तरह से या दूसरे आपको कोड निर्भरता को नियंत्रित करने की आवश्यकता है।

— मार्सिन

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

— पांडिंस्क

हाँ यह इसके लायक था। पुन: प्रयोज्यता के दरवाजे खुले रखना हमेशा इसके लायक है।

— चनी

सवाल यह है: क्या आप आगे के विकास की उम्मीद करते हैं? प्रक्रियात्मक प्रोग्रामिंग सबसे आसान और सबसे तेज़ तरीका है जब आप जानते हैं कि वास्तव में आपको क्या चाहिए और यह बदलने वाला नहीं है। प्रक्रियात्मक कोड में कोई भी परिवर्तन दर्द होगा, ओओपी में यह बहुत आसान होगा।

— कामिल तोमिक्क

Answer 1

मेरे कोड को OOP की किसी भी सुविधा की आवश्यकता नहीं है

आपने अपने स्वयं के प्रश्न का उत्तर दिया है - यदि आपको इस मामले में OOP की आवश्यकता नहीं है और आपकी परियोजना काम कर रही है तो इसे परिवर्तित न करें।

हालाँकि, आपको अपने अगले प्रोजेक्ट के लिए OOP का उपयोग करना चाहिए - लेकिन केवल तभी जब यह उपयुक्त हो।

प्रक्रियात्मक प्रोग्रामिंग के साथ आंतरिक रूप से कुछ भी गलत नहीं है - जब तक यह उचित स्थान पर उपयोग किया जाता है।

Comments

+1 सहमत "आपको अपनी अगली परियोजना के लिए OOP का उपयोग करना चाहिए"।

— Cary Chow

+1 हाँ, अगर यह सही ढंग से काम कर रहा है तो इसे ठीक न करें।

— सेटज़ामोरा

मैं कहूंगा, अगर यह अभी सही ढंग से काम कर रहा है, तो इसे न बदलें, लेकिन आप कभी नहीं जानते कि अगला फीचर अनुरोध क्या होने जा रहा है।

— जेएफओ

"आपको अपने अगले प्रोजेक्ट के लिए OOP का उपयोग करना चाहिए", लेकिन इसका उपयोग तब तक न करें जब तक कि यह समझ में न आए। कुछ चीजें बेहतर तरीके से लिखी जाती हैं, कुछ OOP के लिए बेहतर हैं। जो भी उचित हो उसका उपयोग करें।

— टीएमएन

@ टीएमएन - यह निहित है - मुझे इसे स्पष्ट करना चाहिए।

— ChrisF

Answer 2

नहीं और नहीं, क्योंकि आपको OOP की आवश्यकता नहीं है।

यदि आपका कार्यक्रम पहले से ही समाप्त हो गया है और संतोषजनक काम कर रहा है, तो 90% से अधिक समय यह किसी भी कारण से समाप्त कोड को फिर से लिखने के लिए समय की बर्बादी है।

ओओपी सभी शक्तिशाली नहीं है, बहुत सारे स्थान हैं जहां ओओपी का उपयोग नहीं किया जाना चाहिए, इसलिए इसका उपयोग न करें क्योंकि ओओपी प्रवृत्ति है।

Comments

"समाप्त कोड" से क्या आपका मतलब है कि यह काम करता है?

— जेएफओ

@ ओफ ओ हां सर! यह सही है :)

— सौरव

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

— स्कीथ

कृपया "बहुत सारे स्थान जहां ओओपी का उपयोग नहीं किया जाना चाहिए" पर विस्तृत करें।

— फाल्कन

@ फाल्कन, भले ही आपका ओओपी कोड कितनी अच्छी तरह से डिज़ाइन किया गया हो, लेकिन अगर समस्या डोमेन स्वयं ओओ मॉडल के लिए खराब है, तो आपका ओओपी डिज़ाइन भद्दा है। समस्या डोमेन के भार हैं जिन्हें कभी भी OOP के संदर्भ में व्यक्त नहीं किया जाना चाहिए ।

— एसके-लॉजिक

Answer 3

मेरे सामान्य प्रतिमानों को लेते हैं (और क्यों तीन प्रमुख प्रतिमानों में से कोई भी सही तरीका या प्रोग्राम करने का गलत तरीका नहीं है):

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

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

जब आप नीति से तंत्र के मजबूत पृथक्करण की आवश्यकता हो तो कार्यात्मक शैली की प्रोग्रामिंग अच्छी होती है। एक कार्यप्रणाली फ़ंक्शन जो एक नीति फ़ंक्शन स्वीकार करता है एक अच्छा पैटर्न है। (मैंने इसके बारे में डी प्रोग्रामिंग भाषा के std.algorithm मॉड्यूल को देखकर सीखा था ।) नीति और तंत्र कोड के बीच की सीमा पर उत्परिवर्तनीय स्थिति को दूर करना आम तौर पर एपीआई को तर्क के लिए आसान बनाता है। यदि उत्परिवर्तनीय स्थिति का निजी तौर पर या तो उपयोग किया जाता है, तो यह कार्यान्वयन विवरण है। कार्यात्मक प्रोग्रामिंग की अन्य ताकत संगामिति है, स्व-स्पष्ट कारणों के लिए।

Comments

प्रत्येक प्रकार के प्रोग्रामिंग प्रतिमान का वर्णन करने और उन्हें कब / कैसे उपयोग करना है, इसके उदाहरण प्रदान करने के लिए महान उत्तर के लिए धन्यवाद।

— केविन पेनो

Answer 4

कोड को कभी भी "OOP की आवश्यकता नहीं" होती है। यह प्रोग्रामर, इनोफ़र है क्योंकि वे विभिन्न तरीकों से सोचने में सक्षम हैं, जो कल्पना करते हैं कि इस या उस विशेष समस्या को "$ PARADIGM" की आवश्यकता है या इस तरह से सबसे अच्छा हल किया गया है।

यह अक्सर ऐसा होता है कि प्रोग्रामर जो केवल एक प्रतिमान जानते हैं, उन्हें लगता है कि उनका प्रतिमान सबसे महान है। एक आकार सभी में फिट बैठता है, और हम सभी को प्रोक्रेस्टस के बिस्तर में सोना चाहिए, अगर यह या वह वर्तमान में फैशनेबल है।

Answer 5

यदि ओओपी की आवश्यकता का स्पष्ट संकेत है तो आपको केवल अपनी परियोजना को ओओपी में बदलना चाहिए। संभावित परिदृश्य जिसमें यह हो सकता है (अन्य के बीच):

• परियोजना को स्केलिंग
• टीम में और अधिक डेवलपर्स को जोड़ना

और यहां तक ​​कि इन परिदृश्यों में अभी भी अपनी परियोजना को OOP में बदलना आवश्यक नहीं हो सकता है।

Comments

अच्छी बात है, लेकिन क्या आप मुझे बता सकते हैं कि प्रॉजेक्ट को स्केल करना या टीम में अधिक डेवलपर को जोड़ना समस्या होगी यदि यह एक प्रक्रियात्मक कोड है?

— सौरव

परियोजना को स्केल करने से आवेदन मॉडल में जटिल संबंधपरक संरचनाएं शामिल हो सकती हैं, जिस स्थिति में, यह ओओपी पर स्विच करने के लिए लाभदायक हो सकता है। यदि एप्लिकेशन बिट से थोड़ा ऊपर उठता है, और लंबे समय में OOP में महसूस या समझना आसान हो जाता है, तो नए डेवलपर्स कोड OOP होने पर तेजी से पकड़ सकते हैं। नॉन-ओओ कोड की विरासत को पीछे छोड़ते हुए परियोजना बाद में बड़ी होने पर एक समस्या बन सकती है। उन मामलों में से एक जहां 'चीजें जिस तरह से हैं क्योंकि वे उस तरह से हैं'

— टिमोथी ग्रोट

यह वही है जो मेरे दिमाग में आया जब मैंने सवाल पढ़ा। वह कहते हैं कि उन्होंने कोड के 13 K लाइनें लिखी हैं। मुझे आशा है कि यह केवल एक बार उपयोग करने से बर्बाद नहीं होगा। और अगर इसका पुन: उपयोग करना है, तो ऊप अवश्य ही बन जाएगा। अन्यथा यह नए डेवलपर्स के लिए एक बुरा सपना बन जाएगा

— Chani

Answer 6

दोनों अच्छे हो सकते हैं, दोनों बुरे हो सकते हैं। लेकिन एक दूसरे की तरह देखने के लिए रेट्रोफिटिंग एक अच्छा विचार नहीं है।

Answer 7

यदि आप सोचते हैं कि OO का आविष्कार क्यों किया गया था, तो आप देखेंगे कि आपको OOP की आवश्यकता नहीं है , लेकिन कभी-कभी यह आपके जीवन को बहुत आसान बना देता है।

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

यह आपको बड़े और बड़े कार्यक्रमों को लिखने की अनुमति देता है, सुरक्षित है कि आपने एक कार्य के अपने विशाल हाथी को सौ चूहों के आकार के कार्यों में बदल दिया है। अतिरिक्त बोनस यह है कि आप इनमें से कुछ 'चूहे' ले सकते हैं और अन्य कार्यक्रमों में उनका पुन: उपयोग कर सकते हैं!

बेशक, वास्तविक दुनिया काफी ऐसी नहीं है, और ऑब्जेक्ट का पुन: उपयोग कभी नहीं किया गया था जिस तरह से इसका इरादा था, लेकिन इसका मतलब यह नहीं है कि यह एक बेकार प्रतिमान है।

क्या बेकार है या तो कोडिंग की शैली पर अधिक निर्भरता है। जो कोई भी एक हजार छोटे, तुच्छ वर्गों के साथ OO करता है, वह वास्तव में इसे सही नहीं कर रहा है - वे अपने लिए (या किसी और) के लिए एक बुरा सपना बना रहे हैं। कोई भी एक प्रक्रियात्मक अनुप्रयोग जो केवल 3 कार्य लिख रहा है, वह भी जीवन को कठिन बना रहा है। सबसे अच्छा तरीका है मिडल ग्राउंड, बड़े-ईश ऑब्जेक्ट (कभी-कभी ऐसे घटक जिन्हें हम एक समय में एक बार जाते हुए देखा जाता है) जो कि उचित मात्रा में स्टैंड-अलोन कोड और डेटा प्रदान कर सकते हैं जो कि पुन: उपयोग होने की अधिक संभावना है अपने बाकी ऐप से अलगाव में।

अगली बार के लिए मेरी सलाह: अपना सामान्य प्रक्रियात्मक कोड लिखने का प्रयास करें, लेकिन अपनी मुख्य डेटा संरचना का एक ही उद्देश्य बनाएं। देखें कि आप कैसे पाते हैं कि इसके साथ काम करना फ़ंक्शन से फ़ंक्शन के आसपास डेटा पास करने से अधिक आसान है।

Answer 8

मेरे कोड को OOP [इनकैप्सुलेशन, इनहेरिटेंस मूल रूप से ...] की किसी भी सुविधा की आवश्यकता नहीं है!

तुम्हें कैसे पता?

क्या आपको इस परियोजना को बनाए रखने की आवश्यकता है? क्या कोई नई सुविधाओं की योजना बनाई गई है? अन्य लोग होंगे जो आपके साथ विकसित होंगे? क्या आपने खुद को दोहराया? क्या कोड को समझना मुश्किल है?

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