6

मुझे पता है कि सिद्धांत में संभव है कि प्रक्रियात्मक भाषाओं जैसे कि सी या MATLAB ऑब्जेक्ट उन्मुख वाले में भी चालू हो। इस सवाल पर काफी अच्छी तरह से चर्चा की गई है here और hereप्रक्रियात्मक भाषाओं में ऑब्जेक्ट उन्मुख सिद्धांतों को लागू किया जाना चाहिए?

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

स्पष्टीकरण

शायद एक उदाहरण के क्रम में है।

मुझे कुछ MATLAB कोड विरासत में मिला है जो कुछ मशीन-लर्निंग एल्गोरिदम लागू करता है। वहाँ मूलतः, एक भी समारोह building_model कि, एक ध्वज के आधार पर पारित किया जा रहा है या तो एक मॉडल को प्रशिक्षित या इसका इस्तेमाल एक भविष्य मूल्य भविष्यवाणी करने के लिए किया जाएगा:

building_model('train', ...) % ... stands for the data with which the model is trained 

और

मॉडल के साथ ही लागू किया गया है building_model के अंदर MATLAB लगातार चर।

मैंने building_model को दो कार्यों में फेंक दिया है, एक प्रशिक्षण के लिए और एक भविष्यवाणी के लिए। मॉडल है कि लगातार चर के रूप में लागू किया जा करने के लिए इस्तेमाल अब externalized है, इसलिए बात करने के लिए:

model = new_model() 
model = model_train(model, ...) 
prediction = model_predict(model) 

यह, मोटे तौर पर बोल रहा है, जहाँ तक मैं MATLAB में OOP की कुछ सुविधाओं की नकल का प्रबंधन कर सकते हैं। मेरा बिल्डिंग मॉडल मॉड्यूल अब एक कन्स्ट्रक्टर और दो विधियों model_train और model_predict के साथ एक वर्ग की तरह काम करता है। मैंने कुछ डिग्री encapsulation हासिल किया है (हालांकि कुछ भी कॉलर model के आंतरिक के साथ fiddling से रोकता है), और सिद्धांत रूप में polymorphism भी समायोजित किया जा सकता है। अतिरिक्त बोनस के रूप में, मुझे model_predictmodel वापस नहीं लौटाता है, इसलिए 0/को वापस नहीं कर सकता है, इसलिए मुझे कमांड/क्वेरी अलगाव लगभग मुफ्त में मिलता है।

(चतुर पाठकों का कहना होगा MATLAB पहले से ही एक वस्तु उन्मुख प्रणाली है। प्रदर्शन और पुराने संस्करणों के साथ संगतता सहित कई कारणों के लिए, मैं इसका इस्तेमाल नहीं कर सकते हैं।)

मैं सी में एक समान तंत्र कल्पना कर सकता जहां आप कुछ डेटा संरचना तैयार करेंगे और उन कार्यों को लिखेंगे जिनके पहले तर्क उस डेटा संरचना का एक उदाहरण होगा।

मैं क्या जानना चाहता हूं, मैं प्रोग्रामिंग के इस तरीके को कितनी दूर धक्का दे सकता हूं? क्या यह एक आम तौर पर स्वीकार्य पैटर्न है (वहां, मैंने शब्द कहा है)? क्या कोई प्रदर्शन समस्या है जिसके लिए मुझे देखना चाहिए?

+1

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

उत्तर

2

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

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

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

+0

+1 "मुझे लगता है कि ओओपी से निपटने के लिए जीयूआई सामान वास्तव में उपयोगी हो सकता है।" इस प्रकार डॉ स्ट्रास्ट्रप ने अपने छात्रों को ओओपी पेश किया। – AraK

-1

ऑब्जेक्ट ओरिएंटेशन सॉफ़्टवेयर इंजीनियरिंग लक्ष्यों को प्राप्त करने के साधन हैं।

लक्ष्य: रखरखाव की आसानी, विस्तारशीलता, संगठित स्रोत कोड (खोजनीयता इत्यादि।)
OO निर्माण: Encapsulation (केवल 'डेटा प्रकार/संरचना' अपने डेटा पर काम कर सकते हैं) के स्वामित्व तरीकों

लक्ष्य: मौजूदा संशोधित किए बिना नई सुविधाओं को विकसित करने की क्षमता, कोड पुन: उपयोग
OO निर्माण : कार्यान्वयन विरासत, बहुरूपता

लक्ष्य: चीजें
OO निर्माण (यदि आप ग्राहकों को बदले बिना एक विशेष प्रकार या संचालन, क्रियान्वयन के परिवर्तन के लिए प्रतिबद्ध करने की जरूरत नहीं है): इंटरफ़ेस विरासत, इंटरफेस, अमूर्त वर्ग

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

आपको याद है, सभी ओओ सिद्धांतों का पालन करने के साथ कोड की एक बड़ी गड़बड़ी विकसित करना बिल्कुल संभव है।

मुझे यकीन है कि दूसरों के अन्य लक्ष्यों और उदाहरण सूचीबद्ध कर सकते हैं (और stackoverflow पदों में तालिकाओं संपादित करने का तरीका जानते हैं)

+3

मैं वास्तव में उस ओओ से असहमत हूं * ऊपर * लक्ष्यों को प्राप्त करने के लिए साधन है। ओओ के आविष्कार से पहले यह सब वास्तव में संभव था। –

संबंधित मुद्दे

 संबंधित मुद्दे