क्या ऑब्जेक्ट ओरिएंटेशन के बिना मेरा प्रोजेक्ट बच सकता है?

Question

मैं एक छोटा MATLAB पैकेज लिख रहा हूं जो एक निश्चित वर्ग संख्यात्मक समस्याओं को हल करेगा। एल्गोरिथ्म के 3 चरण हैं और उपयोगकर्ता के पास प्रत्येक चरण के लिए 5 विकल्प हैं। मैंने पूरी समस्या का उपयोग करके लागू किया है$\approx 20$फ़ंक्शन और 3 स्विच मामले (प्रत्येक एल्गोरिथ्म चरण के लिए एक)। यह ठीक काम करता है लेकिन मैं इसे और अधिक चीजें करने पर विचार कर रहा हूं (5 से अधिक विकल्प और एक और चरण) और पायथन पोर्ट (कुछ लोग रुचि रखते हैं) भी बनाते हैं।

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

कृपया इसे SO पर माइग्रेट करें यदि आपको लगता है कि यह उनके डोमेन में अधिक उपयुक्त है।

Answer 1

ऑब्जेक्ट ओरिएंटेशन से लाभान्वित होने के लिए जहां इसे मदद मिलती है, वहां ओओपी फ्रेमवर्क में बदलने की आवश्यकता नहीं है। ध्यान दें कि इन कार्यों के भीतर या इन कार्यों की लंबाई के बीच कोड दोहराव की तुलना में फ़ंक्शन की संख्या एक संकेतक से कम है। (कोड की 100 से अधिक लाइनों वाला एक फ़ंक्शन "सुधार क्षमता" के लिए एक विशिष्ट संकेत होगा।)

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

यदि आप deal.II या PETSc जैसे ढांचे का उपयोग करना चाहते हैं, तो उनका उपयोग करें यदि वे जो कार्यक्षमता प्रदान करते हैं वह आपके लिए उपयोगी है, इसलिए नहीं कि आपको लगता है कि यह आपके स्वयं के कोड को बेहतर या अधिक बनाए रखेगा। लेकिन आप पहले से ही MATLAB ढांचे के भीतर हैं, इसलिए यह संभावना नहीं है कि आप इसके बजाय C ++ OOP ढांचे में बदलना चाहते हैं। (MATLAB पूर्ण OOP समर्थन प्रदान करता है, जैसा कि आप शायद पहले से ही जानते हैं।)

पायथन पोर्ट के लिए, बस एक शुरुआत के लिए अपने वर्तमान ज्ञान के आधार पर करें, और बाद में दूसरी शुरुआत करें जब आपने इसे काफी बेहतर बनाने के लिए पर्याप्त सीखा।

Comments

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

— ज्योफ ऑक्सीबेरी

Answer 2

यह सवाल स्टैक ओवरफ्लो के लिए एक अच्छा फिट हो सकता है। मुझे लगता है कि यह यहां भी एक अच्छा फिट है क्योंकि यह कम्प्यूटेशनल साइंस में एक सामान्य मुद्दा है।

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

Comments

मेरे साथ षड्यंत्र रचा गया। क्या आप पेट्स को ओओपी या प्रक्रियात्मक कोडिंग से सीखने के लिए एक अच्छे पुस्तकालय के रूप में प्रस्तावित कर रहे हैं? क्या आप किसी भी पठनीय पुस्तकालय के बारे में जानते हैं जो OOP अच्छी तरह से करता है?

— inquest

मुझे लगता है कि पेट्सक बड़े सॉफ्टवेयर का एक अच्छा उदाहरण है, और यह आमतौर पर बहुत अच्छी तरह से प्रलेखित है। कम्प्यूटेशनल विज्ञान में, मुझे लगता है कि PETSc, Trilinos, deal.II और FEniCS अच्छी तरह से प्रलेखित होने का अच्छा काम करते हैं, और ये सभी OOP शैली में लिखे गए हैं। मुझे यह कहने में संकोच है कि आपको उनसे OOP सीखना चाहिए; आप शायद पहले पाठ्यपुस्तक से सीखना बेहतर समझते हैं, और फिर वास्तविक विश्व कोड देख रहे हैं।

— ज्योफ ऑक्सबेरी

Answer 3

नहीं सब कुछ अच्छी तरह से वस्तुओं द्वारा मॉडलिंग की है। विचार करें$1 + 1$, आमतौर पर एक OO सिस्टम, 1वस्तुओं और +एक विधि के रूप में एस का इलाज करेगा 1.plus(1), लेकिन यह हमारी प्राकृतिक व्याख्या के अनुरूप नहीं है$1+1$एक बाइनरी इन्फिक्स फ़ंक्शन के रूप में plus(1,1); यह 1उस वस्तु के रूप में पहले के बीच एक अप्राकृतिक विषमता का परिचय देता है जिसके लिए विधि plusको परिभाषित किया जाता है, और दूसरा जो उस पद्धति का तर्क है (यह जैसे __plus__और __rplus__पायथन में कीचड़ को जन्म देता है )।

तो महसूस न करें कि आपको चौकोर खूंटी को गोल छेद में डालने की आवश्यकता है, यदि आप एल्गोरिथ्म सादे प्रक्रियात्मक फैशन में अच्छे लगते हैं तो इसे ऐसे ही रखें। यदि इसे OO प्रणाली में शामिल करने की आवश्यकता है, तो आप हमेशा अपने गैर-OO कोड पर OO इंटरफ़ेस डाल सकते हैं। सी ++ कोडर हर दिन ऐसा करते हैं (और इसके लिए भुगतान भी करते हैं)।