प्रतिरूपकता, अच्छी वास्तुकला, सी / सी ++ और रंगीन हलकों में निर्भरता इंजेक्शन के बारे में

_{सामूहिक रूप से एकता की तलाश नहीं है, लेकिन अधिक - अलगाव की एकरूपता में।
कोजमा छड़}

शुरुआत में कुछ पानी

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

"सॉफ्टवेयर आर्किटेक्चर" की अवधारणा के कारणों में से एक जटिलता को प्रबंधित करने की आवश्यकता है। इस क्षेत्र में, घटक मॉडल से बेहतर कुछ भी अभी तक आविष्कार नहीं किया गया है। यहां तक ​​कि IEEE सॉफ्टवेयर आर्किटेक्चर विवरण मानक किसी परियोजना को घटकों में तोड़ने के सिद्धांत पर आधारित हैं। घटक अच्छे हैं, उनके पास खराब कनेक्टिविटी, पुन: प्रयोज्य और अंततः, अच्छी वास्तुकला है।
बदले में, प्रोग्रामिंग (व्यापक अर्थ में) मोटे तौर पर एक पाठ विवरण के रूप में आभासी दुनिया की संरचना और वर्णन करने का प्रयास है। और सबकुछ ठीक हो जाएगा, लेकिन दुनिया (यहां तक ​​कि आभासी) वस्तुओं / घटकों को बातचीत करने के एक सेट की तुलना में थोड़ा अधिक जटिल है। "पास-थ्रू" नामक एक कार्यक्षमता है, जो किसी एक स्थान पर निहित नहीं है, लेकिन अन्य मॉड्यूल द्वारा "फैल गया" है। उदाहरण पाठ्यपुस्तक हैं: लॉगिंग, ट्रेसिंग, त्रुटि से निपटने, और "गैर-तुच्छ" वाले, जैसे कि सुरक्षा, वर्चुअल मेमोरी सपोर्ट या मल्टीप्रोसेसिंग। इन सभी मामलों में, मुख्य मॉड्यूल के अलावा (लॉगिंग के मामले में, यह फ़ंक्शन हो सकता है जो लॉग प्रदर्शित करता है) अभी भी कुछ "कुछ" है जिसे अन्य मॉड्यूल में जोड़ने की आवश्यकता है। इसके अलावा, इन मॉड्यूल को इसके बारे में पता नहीं है। इसे पहलू कहा जाता है। मॉड्यूल में पहलुओं को पेश करने के मुद्दे का समाधान जो इन पहलुओं के बारे में कुछ भी नहीं जानता है, वास्तव में, पहलू-उन्मुख प्रोग्रामिंग (एओपी) में शामिल है।
एओपी के करीब एक अवधारणा निर्भरता (ओटी) का कार्यान्वयन है। यद्यपि वे अक्सर एक-दूसरे के विरोधी होते हैं, वास्तव में उनके बीच मतभेदों की तुलना में अधिक आम है। मुख्य अंतर यह है कि एओपी मानता है कि लक्ष्य मॉड्यूल को कुछ भी नहीं पता है कि इसमें क्या और कैसे एम्बेड किया जा सकता है। इस पद्धति में कमियां हैं कि मैं यहां सूचीबद्ध नहीं करूंगा, ताकि सामान्य रूप से प्रोग्रामिंग के दर्शन में न झुकें। मैं केवल यह नोट करता हूं कि AOP समस्या को "गैर-तुच्छ पहलुओं" से हल नहीं कर सकता है जब कोड को एल्गोरिथ्म के आधार पर कुछ विशेष बिंदुओं पर एम्बेड करने की आवश्यकता होती है (पहलू कॉलिंग फ़ंक्शंस जैसे फ़ंक्शन से जुड़े होते हैं, फ़ंक्शन से लौटते हैं, आदि)। डिपेंडेंसी इंजेक्शन यहां स्टेज लेता है। अच्छा OT क्या है? सबसे पहले, शुरू किए गए पहलू और मॉड्यूल का इंटरफ़ेस परिभाषित हो जाता है और लक्ष्य मॉड्यूल में सिंटैक्स और फ़ंक्शन नामों से बंधा नहीं होता है। यह "स्रोत स्तर मॉड्यूल" के निर्माण का मार्ग प्रशस्त करता है, जिसके बारे में मैं इस लेख में चर्चा करूंगा (मॉड्यूलरिटी स्वयं एक अलग बड़ी चर्चा का विषय है)। VZ और AOP के बीच क्या आम है? कम से कम तथ्य यह है कि ओटी, साथ ही एओपी, आपको कुछ तृतीय-पक्ष कोड (पहलुओं) को लागू करने की अनुमति देता है, जिनमें से लक्ष्य कोड के सभी संभावित विकल्प नहीं जानते हैं। मूलभूत अंतर केवल इतना है कि क्लासिक एओपी में, कार्यान्वयन बिंदुओं को पहलू के कोड में ही वर्णित किया जाता है, और ओटी के मामले में, कोड को कॉल कोड में इंटरफ़ेस विधियों में पहले से ही लक्षित कोड में एम्बेड किया जाता है।
जावा / सी # अनुयायी यथोचित तर्क देंगे कि वीजेड केवल एक डिज़ाइन पैटर्न है जिसे किसी भी भाषा में लागू किया जाता है, बस एक ऑब्जेक्ट बनाने और उसके तरीकों को कॉल करने के लिए, आपको एक फैक्ट्री विधि को कॉल करने की आवश्यकता है जो कुछ बाहरी कॉन्फ़िगरेशन का विश्लेषण करेगी और आपको जो आवश्यक है वह बनाएगी। लेकिन फिर से, चूंकि हम एम्बेडेड के संदर्भ में हैं, इसलिए कोई अप्रत्यक्ष अप्रत्यक्षता और गतिशील कॉन्फ़िगरेशन नहीं होना चाहिए, क्योंकि इसका प्रदर्शन पर सबसे सीधा प्रभाव पड़ता है। जहां तक ​​संभव हो, सब कुछ स्थिर होना चाहिए।
इस प्रकार, यह पोस्ट इस बारे में है कि कैसे (और क्यों) सी / सी ++ परियोजनाओं के लिए एक स्थिर निर्भरता इंजेक्शन बनाना संभव है, यह किन समस्याओं को हल कर सकता है, और इसके साथ आपके जीवन को कैसे आसान बना सकता है।

बड़े एम्बेडेड प्रोजेक्ट्स की बारीकियां

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

क्यों C / C ++ प्रोजेक्ट्स को कॉन्फ़िगर करना मुश्किल है

C / C ++ में मॉड्युलैरिटी के बारे में बात करें, जितना कि ये भाषाएं खुद मौजूद हैं। अक्सर, एक सॉफ्टवेयर कॉन्फ़िगरेशन प्रबंधन इंजीनियर की तरह कुछ रिक्ति सूची में चमकती है, और हालांकि, पहली नज़र में, यह एक "बाधा के निदेशक" जैसा कुछ लगता है, समस्या वास्तव में प्रासंगिक से अधिक है। यद्यपि यह समस्या न केवल C / C ++ में मौजूद है, बल्कि यह भी है कि यह विशेष रूप से महत्वपूर्ण है क्योंकि इन भाषाओं का उपयोग उन परियोजनाओं में किया जाता है जो प्रदर्शन-महत्वपूर्ण हैं, और जिनके कारण गतिशील कॉन्फ़िगरेशन विधियों का उपयोग अक्सर अस्वीकार्य है। प्रारंभ में यह मान लिया गया था कि C / C ++ में प्रतिरूपकता केवल पुस्तकालय स्तर पर ही होनी चाहिए। इसे सत्यापित करने के लिए, बस C / C ++ प्रोजेक्ट्स (विशेष रूप से C) के विशाल बहुमत के स्रोत संरचना को देखें। "मॉड्यूल" के सबफ़ोल्डर्स में शामिल फ़ोल्डर होता है, जिसमें संपूर्ण प्रोजेक्ट के हेडर होते हैं, जो सभी मॉड्यूल के लिए सुलभ होता है। यह "संदर्भ पथ" है। पूरे प्रोजेक्ट, इसलिए, एक मोनोलिथ एक मैक्रो प्रोसेसर और बिल्ड सिस्टम के साथ कॉन्फ़िगर किया गया है। एक नया मॉड्यूल जोड़ना अपने हेडर को साझा किए गए फ़ोल्डर में जोड़ना, नए #include निर्देशों को जोड़ना, बिल्ड सिस्टम के कॉन्फ़िगरेशन को बदलना और कई अन्य छोटी चीजें हैं, जिसके बाद मॉड्यूल मॉड्यूल होना बंद हो जाता है और परियोजना का एक अभिन्न अंग बन जाता है। एक मॉड्यूल को एक परियोजना से अलग से संकलित नहीं किया जा सकता है, और एक परियोजना को एक मॉड्यूल के बिना संकलित नहीं किया जा सकता है। हेडर के साथ वैश्विक फ़ोल्डर के लिए अभिविन्यास भी अन्य परियोजनाओं में मॉड्यूल का पुन: उपयोग करना मुश्किल बना देता है, बस फाइलों की नकल करना सबसे अच्छे रूप में संकलन त्रुटियों का उत्पादन कर सकता है (सबसे खराब स्थिति में, फाइलें केवल परियोजना के पेड़ में झूठ होंगी और संकलित नहीं की जाएंगी)। एक अतिरिक्त समस्या एक दूसरे से फ़ाइल निर्भरता को मैन्युअल रूप से बनाए रखने की आवश्यकता है, साथ ही "निर्देशिकाओं को शामिल करें" की सही सूची का निर्धारण करना है। हालांकि, यह स्पष्ट है कि यदि प्रोजेक्ट में फ़ंक्शन के प्रोटोटाइप वाली हेडर फ़ाइल शामिल है, तो असेंबली में स्वयं फ़ंक्शंस (कार्यान्वयन) को भी शामिल किया जाना चाहिए।
कई कॉन्फ़िगरेशन विकल्प नहीं हैं, मुख्य रूप से तीन तरीकों का उपयोग किया जाता है, इसलिए "समय-परीक्षण" बोलने के लिए। पहला है # ifdef- # elif- # endif। कोड में प्रत्येक बिंदु, जिसका व्यवहार विन्यास के आधार पर भिन्न हो सकता है, # ifdef द्वारा फंसाया जाता है और सामान्य "कॉन्फ़िगरेशन" शीर्षक से परिभाषाओं पर निर्भर होना शुरू होता है। समस्या तब शुरू होती है जब आपको एक और विकल्प # मेल जोड़ने की आवश्यकता होती है। यदि ऐसे #ifdefs समान रूप से सैकड़ों फ़ाइलों में वितरित किए जाते हैं, तो इन सभी फ़ाइलों में कुछ जोड़ने का विचार पागल दिखता है। मैं इसे एक "बंद" कॉन्फ़िगरेशन सिस्टम कहता हूं, ifdef विकल्प मूल रूप से सिस्टम डेवलपर के रूप में कई हैं, आप स्रोत को बदले बिना कुछ और नहीं जोड़ सकते।
दूसरी विधि बिल्ड सिस्टम पर निर्भर करती है, कुछ फ़ंक्शन में कई संभावित कार्यान्वयन होते हैं, वांछित कार्यान्वयन बिल्ड सिस्टम कॉन्फ़िगरेशन द्वारा निर्धारित किया जाता है। उदाहरण के लिए, यदि प्रोजेक्ट लॉग को print_log फ़ंक्शन के माध्यम से प्रदर्शित किया जाता है, तो इस फ़ंक्शन के कई कार्यान्वयन हो सकते हैं। इस विधि का मुख्य नुकसान रनवे ओवरहेड है। यदि हमें कुछ फ़ंक्शन के लिए कॉल को अक्षम करना है, तो हम एक स्टब मॉड्यूल लिख सकते हैं, लेकिन कुछ फ़ंक्शन को वैसे भी बुलाया जाना चाहिए।
अंत में, तीसरी विधि वर्चुअल हेडर फाइलें हैं। फ़ाइल सिस्टम टूल्स का उपयोग करते हुए, cpu.h जैसे सार हेडर नामों को बांह या x86.h जैसे कंक्रीट वाले से मैप किया जाता है। हेडर की ऐसी खूबी हेडर की जगह और "खाली" मैक्रोज़ के साथ फ़ंक्शन को बदलने के द्वारा अनावश्यक कार्यक्षमता को अक्षम करने में मदद करता है, इसमें "खुलापन" है: आप किसी हेडर को स्रोत को बदले बिना स्थानापन्न कर सकते हैं। लेकिन, दुर्भाग्य से, हेडर और कार्यों के बीच कोई संबंध नहीं है, जिसमें आवश्यक कार्यों का कार्यान्वयन होता है। सेटिंग्स, अमूर्त हेडर नामों, विशिष्ट नामों और बिल्ड सिस्टम के बीच यह स्थिरता फिर से मैन्युअल रूप से बनाए रखी जानी चाहिए। इसके अलावा, यह हमेशा स्पष्ट नहीं होता है कि कौन से नाम और क्या कॉन्फ़िगर किए जा सकते हैं। परिणामस्वरूप, एक खराब प्रलेखित परियोजना फिर से असमर्थित हो जाती है।
बेशक, डेवलपर्स की कल्पना इन तीन तरीकों तक सीमित नहीं है, और विभिन्न परियोजनाओं में आप विभिन्न प्रकार के कॉन्फ़िगरेशन विधियों को पा सकते हैं। कहीं शेल स्क्रिप्ट का उपयोग किया जाता है जो गोंद स्रोत उत्पन्न करते हैं (मुख्य रूप से स्रोत हेडर और असेंबली सिस्टम फाइल दोनों को परिभाषित करने के वितरण को व्यवस्थित करने के लिए), कहीं सीएमके / स्कैन्स, आदि। इन तरीकों की बहुतायत फिर से बताती है कि फिलहाल कोई आम सहमति नहीं है और कॉन्फ़िगरेशन समस्या को हल करने के लिए कुछ सामान्य तरीके हैं।

चाँदी की गोली

इन समस्याओं को कैसे हल किया जाए इसका केंद्रीय विचार यह है कि निर्भरता के बारे में जानकारी स्रोत कोड में ही होनी चाहिए। हेडर फ़ाइलों और कार्यान्वयन के बीच का कनेक्शन स्पष्ट होना चाहिए, और न केवल डेवलपर के सिर में। पास्कल में कुछ दशक पहले भी कुछ ऐसा ही था (हॉल में स्पीकर के आरोपों को सुना जाता है)। पुराने समय के लोग याद करते हैं कि पास्कल मॉड्यूल में इंटरफ़ेस और कार्यान्वयन के दो खंड होते हैं, और समावेश के रूप में <मॉड्यूल नाम> का उपयोग करता है। इस संस्करण में, स्रोत कोड में ही निर्भरता के बारे में सभी जानकारी थी और अकेले स्रोत कोड से एक पूर्ण निर्भरता ग्राफ का निर्माण करना संभव था और यह समझना कि किसी प्रकार के मॉड्यूल के निर्माण के लिए क्या संकलित किए जाने की आवश्यकता है।
मैं स्रोत कोड में कुछ जानकारी जोड़ना चाहूंगा जो बाहरी स्रोत विश्लेषण प्रणाली को उनके बीच निर्भरता को ट्रैक करने में मदद करेगा।
इस समस्या के समाधान की तलाश करते समय, यह सभी के लिए स्पष्ट था कि वह समय जब भाषा के लिए इस परिमाण के क्रमिक परिवर्तन करना संभव हो गया था। यहां तक ​​कि सॉफ्टवेयर उद्योग के दिग्गजों को जीवन के लिए एक नई भाषा लाने के लिए बहुत सारे संसाधनों की आवश्यकता होती है, न कि होली के पवित्र में कुछ बदलाव करने का उल्लेख करने के लिए - सी / सी ++, जो पहले से ही बहुत सारे कोड में लिखा गया है। इसलिए, मुझे केवल मानक प्रस्ताव के साथ ही संतुष्ट रहना था। किसी फ़ाइल में कुछ चिह्न लिखने के कई तरीके हैं, मुख्य प्रश्न यह था कि कैसे "नियंत्रित आयात" (शामिल करें) किया जाए, और निर्भरता को भी ट्रैक किया जाए। समावेशन के लिए, विकल्प छोटा है, मानक के अनुसार, आप केवल फ़ाइल नाम (उद्धरण चिह्नों या कोण कोष्ठक) और मैक्रोज़ में लिख सकते हैं। यह उत्तरार्द्ध था जिसने समस्या को हल करने की कुंजी दी। लेकिन पहले बातें पहले।
आगे की हलचल के बिना, हेडर और स्रोतों में समान पास्कल टैग जोड़ने का निर्णय लिया गया। इंटरफ़ेस की तरह कुछ: प्रभाव लेबल। वास्तव में उन्हें क्या किया जाना चाहिए, इस बारे में कई चर्चाएं हुईं, लेकिन अंततः # प्रागमा पर बस गए। अभी भी संदेह है कि क्या इस रूप में टैग बनाने के लायक था (और अज्ञात प्रज्ञा की तरह चेतावनी के पैकेट प्राप्त करना)। सैद्धांतिक रूप से, #pragma आपको बायनेरिज़ को आयात / निर्यात के बारे में जानकारी जोड़ने की अनुमति देता है, फिर स्रोत कोड और लाइब्रेरी दोनों कॉन्फ़िगरेशन प्रक्रिया में भाग ले सकते हैं। मैक्रो का उपयोग करने वाले संस्करण विकसित किए गए थे (और विकसित किए जा रहे हैं) (मूल्यों का प्रतिस्थापन जो स्रोत विश्लेषण के चरण में होता है, और काम करने वाली फ़ाइल में एक खाली मैक्रो स्टब होता है)। यह मुद्दा विवादास्पद बना हुआ है।
जैसा कि ऊपर उल्लेख किया गया है, प्रत्येक नेता के अंदर एक लेबल होना चाहिए

#pragma fx interface <interface_name>:<impl_version> 

जहाँ <interface_name> इंटरफ़ेस का नाम है, और <impl_version> एक विशिष्ट कार्यान्वयन (संस्करण, संस्करण, आदि) की पहचानकर्ता है। यही है, प्रत्येक घटक के पास एक अनूठा लेबल होना चाहिए। उन घटकों के लिए जहां इंटरफ़ेस समान है, interface_name भाग को भी मेल खाना चाहिए। कार्यान्वयन के बीच अंतर करने के लिए एक संस्करण या कार्यान्वयन की आवश्यकता होती है। कार्यान्वयन फ़ाइल में एक समान लेबल होना चाहिए, केवल fx इंटरफ़ेस के बजाय - fx कार्यान्वयन। हेडर और स्रोतों में लेबल के बीच अंतर करने के लिए विभिन्न इंटरफ़ेस / कार्यान्वयन प्रागमों की आवश्यकता होती है (इसे फ़ाइल एक्सटेंशन से क्यों नहीं समझा जा सकता है नीचे चर्चा की जाएगी)।
इस प्रकार, एक घटक, उदाहरण के लिए, एक हेडर और sysn फ़ाइलों में एक ही interface_name और संस्करण लेबल होना चाहिए इसकी सभी फाइलें, केवल हेडर में #pragma fx इंटरफ़ेस होगा, और स्रोत में प्राग fx कार्यान्वयन होगा। एक ही घटक के एक और कार्यान्वयन (एक ही इंटरफ़ेस के साथ) में इसकी सभी फ़ाइलों में समान लेबल होना चाहिए, लेकिन संस्करण पहले घटक में लिखे गए से अलग होना चाहिए, आदि। #Include का उपयोग करते हुए कुछ का समावेश इंटरफ़ेस नाम का उपयोग करना चाहिए, न कि फ़ाइल नाम, हमेशा की तरह। वर्तमान कार्यान्वयन में, इसके लिए एक मैक्रो का उपयोग किया जाता है

 FX_INTERFACE(<interface>,<impl_version>) 

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

 /*   module_a.h.     VER1 */ … #pragma fx interface A:VER1 

कार्यान्वयन को mod_a.c में परिभाषित किया गया है:

 /*   A  VER1 */ #pragma fx implementation A:VER1 

मॉड्यूल A का उपयोग करने वाले (संदर्भित) मॉड्यूल B बनाएँ:

 /* Module_B.h.   A */ #include FX_INTERFACE(A, VER1) … /*   B  VER1 */ #pragma fx interface B:VER1 

फ़ाइल "मॉड्यूल_बी.सी" में मॉड्यूल बी का कार्यान्वयन:

 /*    */ #include FX_INTERFACE(B, VER1) … /*   B  VER1 */ #pragma fx implementation B:VER1 

इससे यह पहले से ही स्पष्ट है कि आप हेडर फ़ाइल पर स्रोत निर्भरता कैसे प्राप्त कर सकते हैं। यदि कोई विशिष्ट इंटरफ़ेस वाले हेडर का उपयोग करता है, तो आपको एक ही कार्यान्वयन टैग वाले सभी कार्यान्वयन फ़ाइलों (एक्सटेंशन c या cpr) को संकलित करने की आवश्यकता है।
अब निर्भरता को ट्रैक करने और यह समझने के लिए कि अगर हमें मॉड्यूल_ बी सी को संकलित करने की आवश्यकता है, तो यह संकलन और मॉड्यूल_ ए सी की आवश्यकता को पूरा करता है? यदि प्रत्येक फ़ाइल में सभी मॉड्यूल शामिल हैं, जिस पर वह शामिल है, एस-एस के रूप में, और प्रत्येक हेडर फ़ाइल में #pragma fx इंटरफ़ेस होता है, तो, फ़ाइल को प्रीप्रोसेसर के साथ संसाधित करने और आउटपुट में सभी #pragma ढूँढने पर, आप समझ सकते हैं कि यह क्या है निर्भरता मॉड्यूल (सभी पाया कार्यान्वयन, सभी पाया इंटरफ़ेस पर निर्भर करता है)। विशेष रूप से, preprocessor के माध्यम से mod_b.c फ़ाइल को पास करके, हमें कुछ ऐसा मिलता है:

 /*       */ #pragma fx interface A:VER1 … /*       */ #pragma fx interface B:VER1 … /*   module_b.c */ #pragma fx implementation B:VER1 

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

 #include FX_INTERFACE(A, DEFAULT) 

हमें एक मॉड्यूल मिलता है जो कुछ अमूर्त इंटरफ़ेस को आयात करता है, और स्रोत स्तर पर कोई जानकारी नहीं है कि किस कार्यान्वयन का उपयोग किया जाएगा। परियोजना वास्तव में मॉड्यूलर हो जाती है, स्रोत में घटकों के बीच संबंधों के बारे में कोई अंतर्निहित जानकारी नहीं रह जाती है।
यह स्पष्ट है कि अमूर्त इंटरफेस का उपयोग करने के मामले में, रिश्तों के बारे में बाहरी जानकारी की आवश्यकता होती है, जिसमें A: DEFAULT = A: VER1 जैसी जानकारी होगी। यह कुछ बाहरी मैपिंग फ़ाइल में निहित हो सकता है। अब, इस मैपिंग फ़ाइल को बदलकर, हम स्वचालित रूप से निर्भरता पर नज़र रखने और स्वचालित रूप से यह पता लगाने के साथ कि विधानसभा में कौन सी फ़ाइलें शामिल की जानी चाहिए, संकलन समय पर काम करने वाला एक पूर्ण विशेषताओं वाला ओटी बना सकते हैं।
मानचित्र को वैश्विक config से अलग कैसे किया जाता है। उसका उल्लेख किया गया है? कुछ अंतर हैं, लेकिन वे महत्वपूर्ण हैं। config.h यह मानता है कि इसे सभी फ़ाइलों में शामिल किया जाएगा और यह कि सभी फ़ाइलों को संकलित करने की आवश्यकता है (शायद उनमें से कुछ की सामग्री को प्रीप्रोसेसर द्वारा पूरी तरह से बाहर रखा जाएगा), और प्रस्तावित मॉड्यूल के ग्राफ के निर्माण और फ़ाइल सूचियों के निर्माण को प्रभावित कर सकता है। असेंबली के लिए, वह है, जिसे संकलित नहीं किया जाना चाहिए - बिल्कुल भी संकलित नहीं किया जाएगा, और निर्भरताएं स्रोत से ही निकाली जाती हैं और, उदाहरण के लिए, कुछ टिप्पणियों को शामिल करके, हम स्वचालित रूप से विधानसभा से कार्यान्वयन फ़ाइलों का अपवाद बिना आवश्यकता के प्राप्त कर सकते हैं। पुलों को मैन्युअल रूप से करने के लिए।
इस तरह से प्राप्त घटक सामान्य स्रोतों की तुलना में खुद को पुन: उपयोग करने के लिए बहुत अधिक वफादार होते हैं, विशेष रूप से, ऐसे मॉड्यूल को केवल प्रोजेक्ट ट्री में कॉपी किया जा सकता है ताकि उनका उपयोग किया जा सके। एक बोनस के रूप में, स्रोत संरचना में पूर्ण स्वतंत्रता है, आप उन्हें फ़ोल्डर्स और दिन में कम से कम 20 बार फ़ाइलों का नाम बदल सकते हैं। आप निर्देशिकाओं को शामिल करने के बारे में भूल सकते हैं, जिसमें निर्देशिकाओं का नाम बदलना, फाइलों का नाम बदलना, मेकफाइल्स में नई दिखाई गई फाइलें दर्ज करना आदि शामिल हैं इसके अलावा, अगर इंटरफेस को अमूर्तता के उचित स्तर पर किया जाता है, तो आप # ifdefs को भी मना कर सकते हैं। सिस्टम "खुला" हो जाता है, किसी भी कार्यान्वयन को एक आभासी हेडर के रूप में निर्दिष्ट किया जा सकता है, और न केवल उन लोगों को जो मूल रूप से प्रदान किए गए थे, जैसा कि #ifdef के साथ भी होगा। मैं सभी संकलक के साथ क्रॉस-प्लेटफॉर्म संगतता के बारे में नहीं बोलूंगा: यहां सब कुछ स्पष्ट है।
एक निर्भरता इंजेक्शन प्रणाली को लागू करने से पहले एक बहुत ही सरल वास्तुकला है। पूरी प्रणाली घटकों का एक फ्लैट सेट है जो एक दूसरे के साथ जुड़ा नहीं है। वास्तुकला, उनके बीच एक पदानुक्रम के रूप में, और बातचीत के एक ग्राफ के रूप में, पूरी तरह से निर्भरता के बारे में जानकारी द्वारा निर्धारित किया जाता है। अवयव, निश्चित रूप से, मनमाने ढंग से जुड़े नहीं हो सकते, वे संभव कॉन्फ़िगरेशन पर प्रतिबंध लगाते हैं, लेकिन यह सभी जानकारी स्रोत से निकाली जा सकती है। सबग्राफ प्रतिस्थापन स्तर पर कॉन्फ़िगरेशन किया जा सकता है।



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



एक अन्य मुद्दा चक्रीय निर्भरता है। दरअसल, यह समस्या "सामान्य" सी में भी मौजूद है, जब कई हेडर एक-दूसरे से जुड़े होते हैं। समान नियम यहां "सामान्य रूप से" कार्य करते हैं, क्योंकि प्रीप्रोसेसर के बाहर कुछ भी उपयोग नहीं किया जाता है, और सभी #include FX_INTERFACE अंततः नाम दर्ज करने के लिए मैप करते हैं, इन फ़ाइलों को सामान्य तरीकों का उपयोग करके फिर से सक्षम होने से बचाया जाना चाहिए: Aifndef / # परिभाषित या # एक बार स्थिति जब दो मॉड्यूल एक-दूसरे पर निर्भर होते हैं, तो स्वीकार्य है, क्योंकि फ़ाइलों को प्रीप्रोसेसर द्वारा अलग से संसाधित किया जाता है, कोई पुनरावृत्ति नहीं होगी, और संभव डुप्लिकेट फ़ाइलों को संकलन के लिए स्रोत सूची से हटा दिया जाता है (यह हैक नहीं है, यह एक विशेषता है: एक ही मॉड्यूल को कई बार शामिल किया जा सकता है , लेकिन इसका मतलब यह नहीं है कि इसके स्रोतों को मेकफाइल में कई बार लिखा जाना चाहिए)।
सामान्य तौर पर, अभी भी समस्याएं हैं, लेकिन जैसा कि वे कहते हैं, "हम इस पर काम कर रहे हैं।"

उदाहरण

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

 /*    .*/ typedef struct _runtime_protection { int magic_cookie; } runtime_protection, *pruntime_protection; /* .*/ void runtime_protection_init(pruntime_protection object, int cookie); int runtime_protection_check(pruntime_protection object, int cookie); /* .*/ #pragma fx interface RUNTIME_PROTECTION:VER1 

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

 /*    .*/ #include FX_INTERFACE(RUNTIME_PROTECTION, DEFAULT) /*«»    .*/ enum { MAGIC_VALUE_SOME_OBJECT = 0x11223344 }; /*       .*/ typedef struct some_object { int dummy; runtime_protection rtp; } some_object, *psome_object; /*    .*/ #define some_object_as_rtp(so) (&((so)->rtp)) /*   some_object.*/ #pragma fx interface SOME_OBJECT:VER1 

ऑब्जेक्ट का कार्यान्वयन बस कार्यों का उपयोग करता है, बिना यह सोचे कि वे क्या हैं और वे कहाँ से आते हैं:

 /*  .*/ #include FX_INTERFACE(SOME_OBJECT, VER1) /*   some_object.*/ #pragma fx implementation SOME_OBJECT:VER1 void some_object_init(psome_object object) { /* «»   .*/ runtime_protection_init( some_object_as_rtp(object), MAGIC_VALUE_SOME_OBJECT); … } void some_object_method(psome_object object) { /*  .*/ If(!runtime_protection_check( some_object_as_rtp(object), MAGIC_VALUE_SOME_OBJECT)) { //Error! Invalid object. } } 

यदि हम प्रकार जाँच अक्षम करना चाहते हैं, तो हमें एक स्टब इंटरफ़ेस लिखने की आवश्यकता है:

 typedef struct _runtime_protection {} runtime_protection, *pruntime_protection; #define runtime_protection_init(obj, magic) /*  ,   .*/ #define runtime_protection_check (1) /*    RUNTIME_PROTECTION.*/ #pragma fx interface RUNTIME_PROTECTION:STUB 

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

FX डीजे

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



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

निष्कर्ष

हाल ही में, C / C ++ में मॉड्यूल का विषय नियमित रूप से उठाया गया है, C ++ मानकीकरण समिति में उन पर चर्चा करने से शुरू होता है और LLVM में उनके समर्थन के लिए Apple के प्रस्तावों के साथ समाप्त होता है। पोस्ट इस समस्या पर एक और नज़र डालती है और इसे हल करने के तरीके बताती है। परिणामी संस्करण, निश्चित रूप से, कुछ कमियां हैं, लेकिन इसे भाषा में किसी भी प्रकार के वाक्यात्मक परिवर्तन की आवश्यकता नहीं है, इसे अब किसी भी प्रोजेक्ट में उपयोग किया जा सकता है और इसके लिए उन कार्यों को हल करता है जिनके लिए बनाया गया था: स्रोत स्तर पर सॉफ्टवेयर मॉड्यूल बनाना, एक विशिष्ट परियोजना की फ़ोल्डर संरचना की स्वतंत्रता, समावेश / स्रोतों में परिवर्तन के बिना मॉड्यूल को अक्षम / प्रतिस्थापित करना, मैन्युअल रूप से निर्भरता, क्रॉस-प्लेटफ़ॉर्म, मानक के साथ संगत 100% का वर्णन करने की आवश्यकता के बिना स्वचालित विधानसभा नियंत्रण। आदि
अभी के लिए बस इतना ही। ध्यान देने के लिए आप सभी का धन्यवाद।