झूठ 2: कोड दुनिया के एक मॉडल के आसपास डिज़ाइन किया जाना चाहिए? [बन्द है]

Question

मैंने हाल ही में थ्री बिग लाइज़ ब्लॉग पोस्ट पढ़ी है और मुझे दूसरे झूठ को सही ठहराने में मुश्किल समय आ रहा है, जिसे यहाँ उद्धृत किया गया है:

(LIE # 2) CODE SHOULD को विश्व का एक मॉडल बनाया जाना चाहिए

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

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

यहाँ विशेष रूप से इस झूठ के साथ मेरी समस्याएं हैं।

1. कोड में मूल्य होता है एक काल्पनिक दुनिया का एक मॉडल / नक्शा होने के नाते काल्पनिक दुनिया में मदद करता है (कम से कम मुझे, व्यक्तिगत रूप से) कोड की कल्पना और व्यवस्थित करने में मदद करता है।

2. एक "रॉकेट" वर्ग का होना, मेरे लिए, एक वर्ग के लिए पूरी तरह से मान्य विकल्प है। शायद "रॉकेट्स" को एजीएम -११४ हेलफायर जैसे रॉकेटों के प्रकारों में तोड़ा जा सकता है, जिसमें पेलोड की ताकत, अधिकतम वेग, अधिकतम मोड़ त्रिज्या, लक्ष्यीकरण प्रकार और इसके आगे, लेकिन फिर भी हर रॉकेट दागे जाने की स्थिति होनी चाहिए। और एक वेग।

3. बेशक 100 रॉकेट की कीमत 1 रॉकेट से अधिक है। यदि स्क्रीन पर 100 रॉकेट हैं, तो उनकी स्थिति को अपडेट करने के लिए 100 अलग-अलग संगणनाएं होनी चाहिए। दूसरा पैराग्राफ ऐसा लगता है जैसे यह दावा किया जा रहा है कि यदि 100 रॉकेट हैं, तो राज्य को अपडेट करने के लिए 100 से कम गणनाओं की लागत होनी चाहिए?

यहाँ मेरी समस्या यह है कि लेखक एक "त्रुटिपूर्ण" प्रोग्रामिंग मॉडल प्रस्तुत करता है, लेकिन इसे "सही" करने का तरीका प्रस्तुत नहीं करता है। शायद मैं रॉकेट वर्ग की सादृश्यता को बढ़ा रहा हूं, लेकिन मैं वास्तव में इस झूठ के पीछे के तर्क को समझना चाहूंगा। विकल्प क्या है?

Comments

@gnat: यह प्रश्न सॉफ्टवेयर डिजाइन के प्रांत के भीतर है , इसलिए मैं इसे कुछ छूट देने के लिए इच्छुक हूं।

— रॉबर्ट हार्वे

उस ब्लॉग पोस्ट को बहुत खराब तरीके से लिखा गया है और वह अपने दावों का अच्छी तरह से बचाव और समर्थन नहीं करता है। मैं इसे बहुत सोचा नहीं होगा।

— whatsisname

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

— मार्टिन माट

यह देखते हुए कि लेखक ने "3 बिग लाइज़" की व्याख्या करते हुए कुल 5 से अधिक पैराग्राफ लिखने की जहमत नहीं उठाई, आपने शायद इस लेख के बारे में सोचने में अधिक समय बिताया है। यदि वह एक प्रयास करने से परेशान नहीं होगा, तो आपको भी नहीं करना चाहिए।

— कालेब

मुझे लगता है कि वह क्या प्राप्त कर रहा है, क्या आपको वास्तव में 100 की आवश्यकता है [शायद गतिशील तरीकों से भी आवंटित किया गया है] "रॉकेट ऑब्जेक्ट्स", जैसा कि पदों की सूची, वेग की सूची, आदि के विपरीत है (सभी पदों की सूची और एक वेगों की सूची का मतलब है कि आप वस्तुओं की सूची के माध्यम से एक भोले पाश लिखने के बजाय प्रत्येक टिक अद्यतन पर वेग को जोड़ने के लिए वेक्टर निर्देशों का उपयोग करने में सक्षम हो सकते हैं)

— रैंडम 832

Answer 1

सबसे पहले, आइए कुछ संदर्भ देखें: यह एक ब्लॉग पर एक गेम डिज़ाइनर लेखन है, जिसका विषय सेल बीई सीपीयू से प्रदर्शन की आखिरी बूंद है। दूसरे शब्दों में: यह कंसोल गेम प्रोग्रामिंग के बारे में है, विशेष रूप से, प्लेस्टेशन 3 के लिए गेम प्रोग्रामिंग कंसोल है।

अब, गेम प्रोग्रामर एक जिज्ञासु गुच्छा, कंसोल गेम प्रोग्रामर और भी अधिक हैं, और सेल बीई एक अजीब सीपीयू है। (वहाँ एक कारण है सोनी प्लेस्टेशन 4 के लिए एक अधिक पारंपरिक डिजाइन के साथ गया!)

इसलिए, हमें इस संदर्भ में उन कथनों को देखना होगा।

उस ब्लॉग पोस्ट में कुछ सरलीकरण भी हैं। विशेष रूप से, यह झूठ # 2 खराब रूप से प्रस्तुत किया गया है।

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

तो, कुछ अर्थों में, लेखक स्पष्ट रूप से गलत है: सॉफ्टवेयर है एक मॉडल। अवधि। कुछ अन्य अर्थों में, वह सही है: उस मॉडल को वास्तव में वास्तविक दुनिया से मिलता-जुलता नहीं है।

मैं एक उदाहरण दूंगा जो मैंने पहले ही वर्षों में कुछ अन्य उत्तरों में दिया था, (इन) प्रसिद्ध परिचय OO 101 बैंक खाता उदाहरण के लिए। यहां बताया गया है कि लगभग हर OO वर्ग में एक बैंक खाता कैसा दिखता है:

class Account {
  var balance: Decimal
  def transfer(amount: Decimal, target: Account) = {
    balance -= amount
    target.balance += amount
  }
}

तो: balanceहै डेटा , और transferएक है आपरेशन ।

परंतु! यहां बताया गया है कि लगभग हर बैंकिंग सॉफ़्टवेयर में एक बैंक खाता कैसा दिखता है:

class TransactionSlip {
  val transfer(amount: Decimal, from: Account, to: Account)
}

class Account {
  def balance = 
    TransactionLog.filter(t => t.to == this).map(_.amount).sum - 
    TransactionLog.filter(t => t.from == this).map(_.amount).sum
}

तो, अब transferहै डेटा और balanceएक है आपरेशन (एक छोड़ दिया लेनदेन लॉग से अधिक गुना)। (आप यह भी देखेंगे कि TransactionSlipअपरिवर्तनीय है, balanceएक शुद्ध कार्य है, TransactionLogएक परिशिष्ट-केवल "लगभग" अपरिवर्तनीय डेटास्ट्रक्चर हो सकता है ... मुझे यकीन है कि आप में से कई पहले कार्यान्वयन में चकाचौंध करने वाली संगीन कीड़े दिखाई देते थे, जो अब जादुई रूप से दूर हैं ।)

ध्यान दें कि ये दोनों मॉडल हैं। ये दोनों समान रूप से मान्य हैं। ये दोनों सही हैं। ये दोनों एक ही चीज के मॉडल हैं। और फिर भी, वे एक-दूसरे के लिए बिल्कुल दोहरे हैं : एक मॉडल में डेटा जो कुछ है वह दूसरे मॉडल में एक ऑपरेशन है, और एक मॉडल में एक ऑपरेशन जो कुछ है वह दूसरे मॉडल में डेटा है।

तो, सवाल यह नहीं है कि आप अपने कोड में "वास्तविक दुनिया" का मॉडल बनाते हैं , लेकिन आप इसे कैसे मॉडल करते हैं।

जैसा कि यह पता चला है, दूसरा मॉडल वास्तव में यह भी है कि वास्तविक दुनिया में बैंकिंग कैसे काम करती है। मैं कम से ऊपर, इस दूसरे मॉडल ज्यादातर अपरिवर्तनीय और शुद्ध, और संगामिति कीड़े, जो वास्तव में बहुत महत्वपूर्ण है, तो आप समझते हैं एक बार भी कुछ समय पहले, जहां था कि नहीं है के लिए प्रतिरक्षा है संकेत दिया के रूप में TransactionSlipरों थे वास्तविक पर्चियां कि चारों ओर भेजा गया घोड़े और गाड़ी के माध्यम से।

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

तो, यह बहुत अच्छी तरह से सच हो सकता है कि एक उच्च-प्रदर्शन PS3 शूटर के कोर गेम इंजन कोड में, एक Rocketप्रकार नहीं होगा , लेकिन फिर भी, दुनिया के कुछ मॉडलिंग चल रहे होंगे, भले ही मॉडल अजीब लग रहा हो किसी को जो कंसोल गेम भौतिकी इंजन प्रोग्रामिंग के क्षेत्र में विशेषज्ञ नहीं है।

Comments

क्या इसका मतलब यह नहीं होगा कि अच्छा कोड वास्तविक दुनिया का मॉडल है और वास्तव में यह वास्तविक दुनिया की गलतफहमी है जो एक खराब मॉडल और इसलिए खराब कोड का कारण बनता है?

— यित्ज़िह

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

— जोर्ग डब्ल्यू मित्तग

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

— user253751

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

— होल्गर

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

— स्टीव जेसप

Answer 2

मैं हर "झूठ" से असहमत हूं वह प्रस्तावित करता है।

TL; DR इस लेख के लेखक अपने लेख को अधिक रोचक बनाने के लिए विवादास्पद होने की कोशिश कर रहे थे, लेकिन तथाकथित "झूठ" को सॉफ्टवेयर डेवलपर्स ने अच्छे कारणों से स्वीकार कर लिया है।

झूठ # 1 - स्केलिंग प्रयोजनों के लिए बिग ओ मायने रखता है। कोई भी परवाह नहीं करता है कि यदि कोई छोटा अनुप्रयोग अधिक समय लेता है जो एकमात्र समय स्थिरांक मामला है, तो वे परवाह करते हैं कि जब वे इनपुट आकार को दोगुना करते हैं तो यह निष्पादन समय को 10 के कारक से गुणा नहीं करता है।

झूठ # 2 - वास्तविक दुनिया के बाद मॉडलिंग कार्यक्रम एक प्रोग्रामर को आपके कोड को 3 साल बाद देखने की अनुमति देता है ताकि यह आसानी से समझ सके कि यह क्या कर रहा है। कोड को बनाए रखने की आवश्यकता है या आपको यह समझने की कोशिश करने में घंटों खर्च करने की आवश्यकता होगी कि कार्यक्रम क्या करने की कोशिश कर रहा है। एक अन्य उत्तर ने सुझाव दिया कि आपके पास अधिक सामान्य कक्षाएं हो सकती हैं जैसे LaunchPadऔर MassiveDeviceMover। ये जरूरी नहीं कि बुरा वर्ग हो, लेकिन आपको फिर भी Rocketकक्षा की आवश्यकता होगी । किसी को कैसे पता MassiveDeviceMoverचलता है कि वह क्या करता है या क्या चलता है? क्या यह पहाड़ों, अंतरिक्ष यान या ग्रहों को स्थानांतरित कर रहा है? यह मूल रूप से इसका मतलब है कि कक्षाओं में जोड़ना MassiveDeviceMoverआपके कार्यक्रम को कम कुशल बनाता है (लेकिन संभवतः अधिक पठनीय और समझने योग्य तरीका है)।

इसके अतिरिक्त, डेवलपर समय की लागत बहुत पहले हार्डवेयर की लागत से अधिक होने लगी। अपने विचारों के सामने अनुकूलन के साथ डिजाइन करने की कोशिश करना शुरू करना एक भयानक विचार है। आप इसे आसान और समझने योग्य तरीके से प्रोग्राम करते हैं और फिर यह पता लगाने के बाद कि आपके प्रोग्राम को चलाने में बहुत समय लग रहा है, अपने प्रोग्राम को ट्वीक करें। मत भूलना: निष्पादन समय का 80% कार्यक्रम के 20% द्वारा उपयोग किया जा रहा है।

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

Comments

मुझे लगता है कि मुझे # 3 से अधिक सहानुभूति है। प्रोग्रामिंग के 30 वर्षों में, बग के विशाल बहुमत, प्रदर्शन के मुद्दे, और अन्य समस्याओं को मैंने देखा है जो डेटा प्रतिनिधित्व को ठीक करके हल किया गया था। यदि डेटा सही है, तो कोड व्यावहारिक रूप से खुद को लिखता है।

— ली डैनियल क्रोकर

# 3 के साथ वास्तविक मुद्दा यह है कि यह सेब की तुलना संतरे से करता है, न कि यह कोड डेटा या इसके विपरीत से अधिक महत्वपूर्ण है।

— डॉक ब्राउन

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

— ली डैनियल क्रोकर

मुझे नहीं लगता कि झूठ # 3 वास्तव में एक झूठ है। फ्रेड ब्रुक्स ने पहले ही दशकों पहले लिखा था: "मुझे अपने फ्लोचार्ट्स दिखाओ और अपनी टेबल्स को छुपाओ, और मैं रहस्यमय बना रहूंगा। मुझे अपनी टेबल्स दिखाओ, और मुझे आमतौर पर तुम्हारे फ्लोचार्ट्स की जरूरत नहीं होगी; वे स्पष्ट हो जाएंगे।" (आजकल, हम शायद इसके बजाय "एल्गोरिदम" और "डेटा प्रकार" या "स्कीमा" के बारे में बात करेंगे।) इसलिए, डेटा का महत्व लंबे समय से जाना जाता है।

— जोर्ग डब्ल्यू मित्तग

@djechlin मेरा कहना था कि डेटा महत्वपूर्ण नहीं है या यह कोड अधिक महत्वपूर्ण है। बस वह डेटा कोड से अधिक महत्वपूर्ण नहीं है। वे दोनों बहुत महत्वपूर्ण हैं और एक-दूसरे पर बहुत भरोसा करते हैं।

— यित्ज़िह ih ’

Answer 3

एक ई-कॉमर्स प्रणाली में, आप "रॉकेट" के साथ एक वर्ग स्तर पर सौदा नहीं करते हैं, आप "उत्पादों" के साथ सौदा करते हैं। तो यह इस बात पर निर्भर करता है कि आप क्या करने की कोशिश कर रहे हैं और आपके वांछित स्तर को अमूर्त करना है।

एक खेल में, यह तर्क दिया जा सकता है कि रॉकेट केवल "चलती वस्तुओं" के कई प्रकारों में से एक है। वही भौतिकी उन पर लागू होती है जो अन्य सभी चलती वस्तुओं के लिए है। तो बहुत कम से कम, "रॉकेट" कुछ और सामान्य "चलती वस्तु" बेस क्लास से विरासत में मिलने वाला है।

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

Answer 4

वास्तविक दुनिया के साथ समस्या यह है कि शापित भौतिकी। हम वास्तविक दुनिया में भौतिक वस्तुओं में चीजों को अलग करते हैं क्योंकि वे अलग-अलग परमाणुओं की तुलना में स्थानांतरित करने के लिए आसान होते हैं, या किसी चीज का विशाल पिघला हुआ स्लैग जो संभवतः एक रॉकेट हो सकता है।

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

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

विकल्प क्या है?

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

तो हाँ, कभी-कभी वास्तविक दुनिया के काम करने के बाद मॉडलिंग कोड, लेकिन यह एक संयोग है । जब लोग OOP के बारे में बात करते हैं, तो ऑब्जेक्ट वास्तविक दुनिया की वस्तु नहीं होते हैं। स्कूलों और ट्यूटोरियल का कहना है कि अन्यथा एक दशक लंबी त्रासदी है।

Comments

+1: प्रोटोकॉल बहुत "वास्तविक दुनिया" अमूर्त हैं। आज की दुनिया में भी, प्रोटोकॉल अधिकारी राज्य की यात्रा के लिए कुछ सबसे महत्वपूर्ण कर्मचारी लोग हैं, उदाहरण के लिए। ओबामा या पुतिन G8 मीटिंग में रेड कार्पेट पर सबसे पहले कौन जाता है? क्या वे गले मिलते हैं या हाथ मिलाते हैं? मैं एक भारतीय बनाम एक भारतीय का अभिवादन कैसे करूं? और इसी तरह। हमारे पास "भौतिक दुनिया" में "चीजें" बहुत सारी हैं जो "चीजें" नहीं हैं। वास्तविक दुनिया की मॉडलिंग का मतलब भौतिक दुनिया में मॉडलिंग करना नहीं है। यहां तक ​​कि अगर Rocketइस आदमी के कोड में एक प्रकार नहीं है , तो मैं शर्त लगाने को तैयार हूं कि फिर भी कुछ मॉडल है ...

— Jörg W Mittag

... वास्तविक दुनिया, भले ही वह "भौतिक" ("टौचेबल" के अर्थ में) के अनुरूप न हो। मुझे वास्तविक "भौतिक" वस्तुओं को खोजने में बहुत आश्चर्य नहीं होगा ("भौतिक विज्ञानी चीजों को पहचान सकता है" के अर्थ में), हालांकि, जैसे कि चतुर्धातुक, दशांश, क्षेत्र, आदि, जो निश्चित रूप से भी हैं " वास्तविक दुनिया की बातें "और" वास्तविक दुनिया के मॉडल "।

— डब्ल्यू पर Jörg W Mittag

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

— जोर्ग डब्ल्यू मित्तग

और जब मैं एक कंसोल गेम भौतिकी इंजन के बारे में सोचता हूं, तो मैं वास्तव में रॉकेट के बारे में नहीं सोचता, और इस तरह मेरे कोड में एक रॉकेट का मॉडल नहीं होना चाहिए। लेकिन मैं शायद कुछ अन्य "वास्तविक दुनिया के विचार" सोच रहा हूं, और कोड में उन लोगों के मॉडल होने चाहिए ।

— जोर्ग डब्ल्यू मित्तग

Answer 5

विकल्प उन चीजों को मॉडल करना है जिनके बारे में आपके कार्यक्रमों की परवाह है। यहां तक ​​कि अगर आपका कार्यक्रम रॉकेट से संबंधित है, तो आपको एक इकाई नामक एक की आवश्यकता नहीं हो सकती है Rocket। उदाहरण के लिए, आपके पास एक LaunchPadइकाई और एक LaunchScheduleइकाई और एक MassiveDeviceMoverइकाई हो सकती है। यह तथ्य कि यह सभी रॉकेट लॉन्च करने में सहायता करते हैं, इसका मतलब यह नहीं है कि आप स्वयं रॉकेट संभाल रहे हैं।

Answer 6

यहाँ मेरी समस्या यह है कि लेखक एक "त्रुटिपूर्ण" प्रोग्रामिंग मॉडल प्रस्तुत करता है, लेकिन इसे "सही" करने का तरीका प्रस्तुत नहीं करता है। शायद मैं रॉकेट वर्ग की सादृश्यता को बढ़ा रहा हूं, लेकिन मैं वास्तव में इस झूठ के पीछे के तर्क को समझना चाहूंगा। विकल्प क्या है?

यह वास्तविक समस्या है, लेकिन मैं आपको एक डेवलपर के रूप में अपना ले जाऊंगा, शायद यह मदद करेगा।

पहले, मैं इसमें से किसी भी झूठ को आम गलतफहमी नहीं कहूंगा। इसे झूठ कहना केवल प्रचार है।

एक वह सही है, कुछ मायनों में। इस पर बहुत समय बिताने के लिए नहीं जा रहा है, क्योंकि यह सवाल का हिस्सा नहीं है। लेकिन संक्षेप में वह सही है। मैं इसे आराम कर सकता हूं क्योंकि "एक लैब में जो काम करता है वह वास्तविक जीवन में काम नहीं कर सकता है"। बहुत बार डेवलपर्स एक डिजाइन के साथ चिपके रहते हैं जो "लैब" में काम करता है लेकिन वास्तविक दुनिया के अनुप्रयोगों में विफल रहता है।

तीन मेरे लिए थोड़ा सा साबुन का डिब्बा लगता है, लेकिन अनिवार्य रूप से वह फिर से सही है। लेकिन इसे फिर से लिखा जा सकता है "अपनी आवश्यकताओं के आसपास कोड लिखने के लिए, अपने कोड के लिए आवश्यकताओं को फिट करने का प्रयास न करें।"

दो फिर, यहाँ वह सही है। मैंने देखा है कि डेवलपर्स हफ्तों या लंबे समय तक एक "रॉकेट" वर्ग विकसित करते हैं जब एक साधारण "वाहन" वर्ग काम करेगा, या एक भी सरल, "चल" वर्ग। यदि आपके सभी रॉकेट को स्क्रीन के बाईं ओर से दाईं ओर जाना है और ध्वनि करना है, तो आप उसी वर्ग का उपयोग कर सकते हैं जो आपने कार, ट्रेन, नाव और मक्खियों के लिए किया था। 100 की लागत कम होनी चाहिए फिर 1 * 100 तर्क विकसित होने में समय लगता है, और गणना लागत में इतना नहीं। हालांकि कम सामान्य वर्गों के लिए चिपके रहना कि पुन: उपयोग किया जाना "सस्ता" है, फिर कई विशिष्ट कक्षाएं जिनका पुन: उपयोग नहीं किया जा सकता है। यह संभवतः फिर से लिखा जा सकता है क्योंकि "सामान्य वर्ग बेहतर होते हैं, फिर विशिष्ट कक्षाओं में,

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

एक आखिरी नोट, लेख 2008 में लिखा गया था (सबसे अच्छा मैं बता सकता था)। चीजें जल्दी बदल जाती हैं। बयान आज सच हैं, लेकिन एम्बेडेड सिस्टम आज और फिर बहुत आम हैं, और फिर विकास पैटर्न बदलते हैं। शायद इस लेख / बात के जवाब में भी।

Answer 7

मुझे यह दिलचस्प है कि ये शैक्षणिक चिंताओं के आसपास स्थित हैं: मंच, स्मृति उपयोग की दक्षता और डेटा। लेकिन यह मानवीय तत्व की पूरी तरह से अनदेखी करता है।

सॉफ्टवेयर लोगों की जरूरतों को पूरा करने के बारे में है। आमतौर पर इसे व्यावसायिक रूप से निर्धारित किया जाता है - ऐसे ग्राहक होते हैं जो कुछ चाहते हैं और पीछे आने वाले लोग ऐसा करने के लिए भुगतान करने को तैयार रहते हैं। यदि सॉफ्टवेयर समीकरण के दोनों पक्षों की जरूरतों को पूरा करने के लिए एक तरह से लिखा जा रहा है, तो यह अच्छा सॉफ्टवेयर है, यदि नहीं, तो यह खराब सॉफ्टवेयर है।

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

बड़ा झूठ यह है कि कुछ भी हो लेकिन मानवीय तत्व मायने रखता है। डेटा क्यों महत्वपूर्ण है? क्योंकि कुछ ग्राहक या हितधारक हैं जिन्हें इसकी आवश्यकता है। वह "बड़ा सच" है।

Comments

दुर्भाग्य से ग्राहक त्वरित और गंदे कोड चाहते हैं जो पढ़ने और बनाए रखने में आसान है, बिना किसी परीक्षण के प्रयासों के साथ सस्ता है, और कोई बग नहीं है।

— गॉनन I

@ user889742 हा! सच। आपने ठीक कहा है कि इंजीनियरिंग समस्या के आर्किटेक्ट हर समय हल करने का प्रयास कर रहे हैं और इस उद्योग में काम करने के लिए इस तरह का एक दिलचस्प स्थान है।

— मूल्य जोन्स

वह मानवीय तत्व को नजरअंदाज करता है क्योंकि वह एक गेम डेवलपर है और एक गेम का रखरखाव युग अपेक्षाकृत कम समय तक रहता है, हालांकि अब 2008 की तुलना में आज अधिक है। डे 1 पैच अब एक दिन में गेमिंग में आदर्श लगते हैं। 2008 में खेलों के लिए पैच अभी भी अपेक्षाकृत दुर्लभ थे।

— रबरडॉक

Answer 8

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