सॉफ्टवेयर आर्किटेक्चर भाषा पर कितना निर्भर करता है?

Question

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

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

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

यदि हाँ, तो वे क्या हैं? दुर्भाग्य से सभी अच्छी तरह से अपनाए गए प्रतिमान (जहां तक ​​मुझे पता है) किसी तरह ओओपी अवधारणाओं और प्रकारों का उल्लेख करते हैं। यदि नहीं, तो मुझे सामान्य भाषा और उपयोग के मामले में सामान्य वास्तुकला और डिजाइन सिद्धांतों का पालन करते समय किन नियमों का पालन करना चाहिए?

सामान्य तौर पर आप वास्तुकला और भाषा के बीच निर्भरता का वर्णन कैसे करेंगे?

Comments

मैंने सॉफ्टवेयर आर्किटेक्चर पर एक लेख लिखा है: सॉफ्टवेयर जटिलता से

— जुड़े लिंक

सबसे पहले, हाँ, सॉफ्टवेयर आर्किटेक्चर आपके मन में मौजूद तकनीक के आधार पर संचालित होता है। उदाहरण के लिए: जब तक उन धागे IO बाध्य नहीं होते हैं तब तक अजगर बहुउद्देशीय का लाभ नहीं उठाता है। यह मल्टी-कोर सीपीयू बाउंड ऑपरेशन के उपयोग में एक वास्तविक सीमा है। दूसरे, आपको यह सुनना चाहिए ... youtu.be/FF-tKLISfPE तीसरा, आपको कम से कम 5-6 वर्षों के लिए, विशिष्ट डोमेन के मौजूदा स्थिर वितरित उद्यम उत्पादों पर विश्लेषण / कार्य करना चाहिए। यह एक जैविक समझ है कि प्रौद्योगिकी डिजाइन को कैसे प्रभावित करती है। Btw..Such उत्पाद खरोंच से पूर्व जावा दुनिया में लिखे गए थे।

— ओवरएक्सचेंज

गलत तकनीक ... जावा दुनिया में, जब तक जावा 5/6/7 भाषा डिजाइन वास्तविक संस्थापकों के नियंत्रण में था। जावा 8 से, मैं जावा को एक प्रचार मशीन के रूप में नहीं बल्कि एक प्रोग्रामिंग भाषा के रूप में मानूंगा। मेरी राय में, जावा एक प्रोजेक्ट मैनेजर की तकनीक बन गई है। इसलिए, एक शुरुआत के रूप में, मैं C / C ++ / Python

— overexchange

कृपया अपने प्रश्न में वास्तुकला शब्द का उपयोग न करें, यह भ्रामक है। आपका प्रश्न डिजाइन के बारे में है। भाषा की पसंद आमतौर पर वास्तुकला के रूप में योग्य होगी, आपका प्रश्न किसी भी तरह से इसका अर्थ नहीं रखता है ..

— मार्टिन माट

इसके अलावा अजगर और जावास्क्रिप्ट करते इंटरफेस है, वे सिर्फ एक अलग कीवर्ड का उपयोग नहीं करते उन्हें हदबंदी के लिए

— Caleth

Answer 1

एक सॉफ्टवेयर आर्किटेक्चर घर या पुल के आर्किटेक्चर को बहुत पसंद करता है। एक पुल को खुद का वजन और उस पर चलने वाले वाहनों या उस पर चलने वाले लोगों को पकड़ना होगा। इसे मौसम का सामना करना होगा। इसे बनाने के लिए आपके द्वारा उपयोग की जाने वाली सामग्री मजबूत और अपेक्षाकृत हल्की होनी चाहिए।

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

उसी तरह, आपके द्वारा उपयोग की जाने वाली प्रोग्रामिंग भाषा आपके आर्किटेक्चर के निर्माण के तरीके को प्रभावित करती है। आपका आर्किटेक्चर एक प्रोग्रामिंग लैंग्वेज में अलग दिखने वाला है जिसमें C ++ जैसी क्लासेस होती हैं, जो प्रोग्रामिंग लैंग्वेज में होती है जैसे C नहीं।

SOLID सिद्धांत ज्यादातर ऑब्जेक्ट-ओरिएंटेड भाषाओं (यानी वर्ग वाली भाषाएं) के बारे में हैं।

Answer 2

आर्किटेक्चर अपने लक्ष्यों को पूरा करने की क्षमताओं पर निर्भर करता है। भाषा के विकल्प क्षमताओं को सीमित कर सकते हैं। किसी भी ट्यूरिंग पूरी भाषा में किसी भी प्रोग्रामिंग कार्य को पूरा करने की क्षमता है। उस बिंदु के बाद यह इस बारे में है कि भाषा कैसे मानव पठनीय समाधान की अनुमति देती है।

कई सॉफ्टवेयर आर्किटेक्चर योजनाएं आपको मुख्य डोमेन व्यवसाय नियमों से प्रौद्योगिकी विकल्पों के सभी ज्ञान को हटाने के लिए कहती हैं। एक तकनीकी विकल्प जिसे आप कभी भी कोर से दूर नहीं कर सकते हैं वह वह भाषा है जिसे आप इसे व्यक्त करने के लिए चुनते हैं।

जब आर्किटेक्चर पर किताबें आपको अपने लक्ष्यों के बारे में बताने के लिए चिपकी रहती हैं तो भाषा इतनी देर तक मायने नहीं रखती क्योंकि यह लक्ष्य हासिल करने में सक्षम है। जब किताबें आपको बताती हैं कि इन लक्ष्यों को कैसे प्राप्त किया जाए तो भाषा की शुरुआत होती है।

Comments

आपके उत्तर में अच्छे अंक, लेकिन यकीन है, ऐतिहासिक रूप से सॉफ्टवेयर आर्किटेक्चर ट्रेंड में प्रौद्योगिकियों के साथ एड को लागू कर रहे थे।

— ओवरएक्सचेंज

@overexchange एक अच्छी वास्तुकला का बिंदु सॉफ्टवेयर का उत्पादन करना है जो अगले एक के लिए तैयार होकर वर्तमान प्रवृत्ति को बाहर कर सकता है।

— कैंडिड_ऑरेंज

मिडलवेयर की दुनिया में कम से कम, उत्पाद आर्किटेक्चर 1990 के दशक तक RPC / RMI / CORBA से आगे सोचने में सक्षम नहीं थे। मैंने क्लासिक डिजाइनों को प्रक्रिया उन्मुख रीमोर कॉल्स पर भरोसा करते हुए देखा। तब ServiceOArch ने आर्किटेक्चर के मामले में मिडलवेयर का चलन बदल दिया।

— ओवरएक्सचेंज

@ सिद्धांत यह सिद्धांत है। व्यवहार में, मैंने बहुत से लोगों को ऐसा करते देखा है जिसे कभी-कभी "प्रचार चालित विकास" कहा जाता है - बस वही करें जो उनके साथियों का वर्तमान चक्र डिज़ाइन के समय सबसे अधिक बात कर रहा है ताकि आप उस बात में भाग ले सकें।

— marstato

@marstato सहमत हैं। सबसे अच्छा उदाहरण, वर्तमान प्रवृत्ति में स्प्रिंग / स्प्रिंगबूट का उपयोग करना, किसी भी नई परियोजना के लिए, बिना जाने, क्यों?

— ओवरएक्सचेंज

Answer 3

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

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

सही बात?

Comments

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

— ट्रिस्टन तजारा

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

— ट्रिस्टन तजारा

मूलतः, क्या SOLID अभी भी ऐसे मामले में खड़ा है? यदि हां, तो कोई इसे कैसे अपनाता है? यदि कोई नहीं करना चाहिए तो क्या होगा?

— ट्रिस्टन तजारा

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

— रिबेल्डेदी

@TristanTzara ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग का आविष्कार पहले, और इसके बिना, किसी भी ऑब्जेक्ट ओरिएंटेड भाषा में किया गया था। आप इसे किसी भी सामान्य प्रयोजन की भाषा में कर सकते हैं। यहां तक ​​कि जिनके पास कक्षाएं नहीं हैं।

— कैंडिड_ऑरेंज

Answer 4

मैं कहूंगा, शुरू करने के लिए, यहां तक ​​कि आपको जो भाषा में लगता है कि आप क्या गर्भ धारण कर सकते हैं में एक गहरा प्रभाव है। एक कारण है कि PASCAL को ब्रिक केर्निघन और डेनिस रिची ने निकलस विर्थ और सी द्वारा बनाया था।

एक उच्च स्तर पर, कुछ अवधारणाओं (और दूसरों की कमी) को व्यक्त करने की क्षमता आपके विचार को निर्देशित करेगी और आपको कुछ ऐसे समाधानों तक पहुंचेगी जो जरूरी नहीं कि एक ही व्यक्ति होंगे, एक अलग पृष्ठभूमि के साथ, एक साथ आएंगे।

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