ऑब्जेक्ट मॉडल?

Question

क्या यह कार्यात्मक शैली में ऑब्जेक्ट मॉडल को लागू करने के लिए व्यावहारिक है?

ओओपी एक समस्या है जो ऑब्जेक्ट मॉडल का वर्णन कर रही है।

उदाहरण के लिए, एक HTML डॉम एक जटिल, राज्यिक जानवर है जो यूआई और के साथ सीधे इंटरफेस करता है गतिशील भाषाओं से प्रोग्राम योग्यता की आवश्यकता होती है।

• सदस्य पहुंच की कमी अविश्वस्त कोड के साथ इंटरफ़ेस कर (जैसे जावास्क्रिप्ट) सुरक्षित
• Accessor कार्यों और गुण
• यूआई के लिए बाध्य कर अधिक सुविधाजनक: OOP सुविधाओं तरीके का एक बहुत में उपयोगी में आने की कोशिश ऑब्जेक्ट मॉडल के चारों ओर गुजरने के लिए हर समय तरीकों को बहुत आसान बनाता है।

यदि आप एमवीवीएम के माध्यम से मॉडल पेश कर रहे हैं तो कहानी का यूआई पक्ष थोड़ा सा हो सकता है, लेकिन आप अभी भी आंतरिक रूप से राज्य के साथ लगातार कुश्ती कर रहे हैं।

मैं इस परियोजना के लिए एफ # में काम कर रहा हूं, इसलिए मैं आसानी से ओओपी का सहारा ले सकता हूं, लेकिन मुझे उत्सुकता है कि यह अव्यवहारिक होने से पहले इसे कितनी दूर धक्का दे सकता है। क्या डिजाइन पैटर्न या कुछ भी हो सकता है?

Answer 1

यह एक "दार्शनिक" उत्तर देने के लिए थोड़ा सा दार्शनिक है लेकिन ठीक है, मैं काट दूंगा।

मेरी राय में समस्या आती है क्योंकि आप एफपी और ओओ को जुटापोज़ मानते हैं, वे नहीं हैं। एफपी और अनिवार्य प्रोग्रामिंग जुड़ा हुआ है, यानी बयानों का उपयोग कर बनाम अभिव्यक्तियों का उपयोग करना।

समस्या का एक हिस्सा यह है कि ओओ की स्पष्ट परिभाषा की कमी है, वैसे भी मेरी राय में। इसका समर्थन करने के लिए मैं एलन के को इंगित करता हूं, जिन्होंने कहा, "असल में मैंने" वस्तु-उन्मुख "शब्द बनाया है, और मैं आपको बता सकता हूं कि मेरे पास सी ++ दिमाग में नहीं है।", फिर भी अधिकांश भाषा जिसे हम ओओ यानी जावा/सी # छोटे से छोटे से सी ++ के बाद अधिक ले लो।

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

जैसा कि आप बहुत सी सी ++/जावा/सी # को इंगित करते हैं, लेकिन उन्हें यह नहीं होना चाहिए कि जावा और सी # दोनों में मूलभूत प्रकार हैं जैसे कि उनके स्ट्रिंग क्लासेस अपरिवर्तनीय हैं। यह सच जावा और सी # अपरिवर्तनीय वर्ग बनाने में आसान नहीं है लेकिन थोड़ा सा प्रयास करके आप इसे कर सकते हैं।

जो हमें अपरिवर्तनीय विनियमित कहां लाता है? मेरे डिज़ाइन में आम तौर पर सबकुछ अपरिवर्तनीय बनाकर शुरू होता है, क्योंकि इससे चीज़ें आसान हो जाती हैं, और यदि मैं इसे प्रदर्शन समस्याओं का कारण बनता हूं तो मैं महत्वपूर्ण पथों पर कुछ परिवर्तनशीलता जोड़ना शुरू करता हूं। एक जगह अपरिवर्तनीयता कभी भी काम नहीं करेगी जीयूआई नियंत्रण है, जिसमें आम तौर पर अपरिवर्तनीय होने के लिए बहुत अधिक राज्य होता है। ऐसा कहा जाता है कि आप एक अपरिवर्तनीय "संयोजक" दृष्टिकोण का उपयोग करके जीयूआई का निर्माण करने में काफी लंबा रास्ता प्राप्त कर सकते हैं, फिर इसे परिवर्तनीय गुई नियंत्रणों द्वारा व्याख्या किया जाता है। यह वेबशेपर लड़का क्या करता है: http://www.intellifactory.com/products/wsp/Home.aspx

एफपी/ओओ बहस के लिए एक और महान संसाधन मस्तिष्क का "कार्यात्मक प्रोग्रामिंग आपके कोड की संरचना को कैसे प्रभावित करता है?" (जिसने एफपी/ओओ के बारे में मेरी सोच को बहुत प्रभावित किया): http://lorgonblog.wordpress.com/2008/09/22/how-does-functional-programming-affect-the-structure-of-your-code/