कक्षाओं के माध्यम से और जावा (जैसे जावा) के लिए सभी कोड को संरचित करने के फायदे और नुकसान


13

संपादित करें: मेरी भाषा जावा के विपरीत कई विरासत के लिए अनुमति देती है।

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

सबसे पहले, मैंने इसे जावा से हटाने का फैसला किया है।

यह निहित है कि सभी कोड कक्षाओं के रूप में लिखे जाएंगे, और यह कोड उन कक्षाओं में संकलित होता है, जिन्हें वीएम द्वारा लोड किया जाता है।

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

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

अब मैं सोच में पड़ गया हूं: संकलन इकाइयों के रूप में कक्षाएं होने के उतार-चढ़ाव क्या हैं?

इसके अलावा, मेरे डिजाइन पर किसी भी सामान्य टिप्पणी की बहुत सराहना की जाएगी। मेरी भाषा पर एक जानकारीपूर्ण पोस्ट यहाँ पाई जा सकती है: http://www.yannbane.com/2012/12/kava.html


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

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

1
@ डायलेन: वास्तव में, आप अभी भी संरचना का उपयोग कर कार्यक्षमता का निर्माण कर सकते हैं।
रॉबर्ट हार्वे

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

@delnan: उपप्रकार और बहुरूपता के लिए विरासत का उपयोग करने में क्या गलत है? यही विरासत है ...
मेसन व्हीलर

जवाबों:


6

संकलन इकाइयों के रूप में कक्षाएं होने के क्या लाभ हैं?

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

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

इस पर गौर करने के बाद, मैं बहुत सी समस्याओं पर निर्भरता के साथ भाग गया, चीजों को ठीक से, और आरंभिक चिंताओं से। आप अंत में उन मुद्दों पर चल रहे हैं जो 'शीर्ष स्तर की कक्षाओं' को विशेष बनाते हैं, और उन्हें काम करने के लिए कई सीमाएँ हैं जो उन्हें सरल नामस्थान में आकार देने का काम करती हैं।


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

@yannbane - मेरा मतलब यह नहीं है object, मेरा मतलब है कि ऐसी कक्षाएं जो आंतरिक कक्षाओं के बजाय मॉड्यूल की तरह व्यवहार कर रही हैं जो जरूरी नहीं कि उनकी संकलन इकाई के बाहर सार्वजनिक हों। यदि आप किसी प्रकार का DLL शैली व्यवहार चाहते हैं, तो विवरणों में 'निर्भरताएँ बाहर' एक विशाल हॉर्नेट के घोंसले में बदल जाती हैं; YMMV। स्थिर के लिए के रूप में ।
तेलस्टिन

उस मॉड्यूल जैसा व्यवहार स्थैतिक तरीकों / चर के उपयोग के माध्यम से प्राप्त किया जाएगा, है ना? क्या यह एक वर्ग बनाने के बजाय बुरा है, जिसे तत्काल बनाया जा सकता है, एक ऐसा वर्ग बनाएं जिसमें केवल स्थिर सदस्य और विधियां हों? मैंने उस लेख को देखा, हालाँकि, मुझे नहीं लगता कि यह निरंतर स्थैतिक सदस्यों पर लागू होता है , न ही स्थैतिक तरीकों पर। उदाहरण के लिए, मुझे एक Mathवर्ग बनाने में कुछ भी गलत नहीं दिख रहा है , जो वास्तव में स्थैतिक विधियों वाला एक मॉड्यूल है और जिसे स्थिर स्थिर डबल सदस्य कहा जाता है Pi
जेकोरा

@ यन्नबाने - नहीं, वास्तव में नहीं। मॉड्यूल मॉड्यूल हैं क्योंकि वे तात्कालिक हैं। अन्यथा आपके पास सिर्फ C ++ शैली के नामस्थान हैं। एक बार जब आप अपने शीर्ष स्तर की कक्षाओं को C ++ शैली के नाम स्थान पर सीमित कर देते हैं, तो वे वास्तव में कक्षाएं नहीं होती हैं।
तेलस्टिन

हम्म, मैं अभी भी ठीक हूं और कक्षाओं के साथ मॉड्यूल बनाने के साथ समस्या को वास्तव में नहीं देखता हूं। और हाँ, मॉड्यूल नेमस्पेस, विशेष रूप से पायथन मॉड्यूल के रूप में कार्य करते हैं।
जकोरा

4

इस प्रश्न का उत्तर देने के बजाय, मैं एक स्तर ऊपर जाऊंगा और MIT ओपनकोर्सवेयर , विशेष रूप से 6.035 (कंप्यूटर इंजीनियरिंग इंजीनियरिंग) का अध्ययन करने का सुझाव दूंगा । यह पूरी समस्याओं को समझाएगा, ताकि आप फिर से इस तरह के सवाल पूछने के लिए परीक्षा में न पड़ें।

कंप्यूटर भाषा इंजीनियरिंग

केवल पूर्व-आवश्यकता जावा है।

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-035-computer-language-engineering-spring-2010/lecture-notes/

पाठ्यक्रम विवरण

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

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.