👩🏾‍🎨 📑 🕠 न्यूनतम के लिए C ++ और जावा में एप्लिकेशन आर्किटेक्चर के निर्माण के लिए एक सार्वभौमिक विधि के रूप में पैरामीटर का पता लगाएं। कीमत 👨🏿‍🤝‍👨🏽 🤚 🖐🏽

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

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

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

अस्वीकरण एन 3 : मैंने स्क्रैच से बड़े एप्लिकेशन लिखे, लेकिन सर्वर और क्लाइंट एंटरप्राइज एप्लिकेशन नहीं लिखे। वहां सब कुछ अलग है और, शायद, मेरा अनुभव इस क्षेत्र के विशेषज्ञों को अजीब लगेगा। और लेख उस बारे में नहीं है, समान स्केलेबिलिटी मुद्दों को यहां बिल्कुल नहीं माना जाता है।
अस्वीकरण एन 4 ( अपडेट। टिप्पणियों के आधार पर): कुछ टिप्पणीकारों ने सुझाव दिया है कि मैं फाउलर को फिर से मजबूत करता हूं और लंबे समय से ज्ञात डिजाइन पैटर्न प्रदान करता हूं। यह निश्चित रूप से ऐसा नहीं है। मैं एक बहुत छोटे पैरामीटर उपकरण का प्रस्ताव करता हूं जो आपको न्यूनतम प्रतिमान के साथ इन पैटर्नों को लागू करने की अनुमति देता है। फाउलर की डिपेंडेंसी इंजेक्शन और सर्विस लोकेटर सहित, लेकिन न केवल - टाइपेडसेट क्लास का उपयोग करके आप आर्थिक रूप से रणनीतियों का एक सेट भी लागू कर सकते हैं। इस मामले में, फाउलर ने लाइनों के माध्यम से एक्सेस किया, जो महंगा है - मेरा शून्य-लागत टूल, शून्य लागत (यदि पूरी तरह से सख्ती से, तो 2M * लॉग (एन) के बजाय लॉग (एन), जहां एम सर्विस लोकेटर के लिए पैरामीटर स्ट्रिंग की लंबाई है)। C ++ 20 में कॉन्स्टैक्स टाइपिड की उपस्थिति के बाद, मूल्य पूरी तरह से शून्य हो जाना चाहिए)। इसलिए, मैं आपसे कहता हूं कि लेख के अर्थ को डिज़ाइन पैटर्न में न बढ़ाएं। यहां आपको इन पैटर्नों के सस्ते कार्यान्वयन के लिए केवल एक विधि मिलेगी।

उदाहरण C ++ में होंगे, लेकिन उपरोक्त सभी जावा में काफी लागू हैं। शायद, समय के साथ, मैं जावा के लिए वर्किंग कोड दूंगा अगर इसके लिए अनुरोध आपसे टिप्पणियों में होगा।

भाग 1. एक वैक्यूम में गोलाकार वास्तुकला

सभी कठिनाइयों को शानदार ढंग से हल करने से पहले, आपको उन्हें सही ढंग से बनाने की आवश्यकता है। सही जगह पर अपने लिए मुश्किलें पैदा करते हुए, आप उनके समाधान की सुविधा प्रदान कर सकते हैं। इसके लिए, हम एक लक्ष्य बनाते हैं जिसके समाधान के लिए हम तरीकों के साथ आएंगे - अच्छी वास्तुकला के न्यूनतम सिद्धांत।

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

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

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

और यह एक गलती से भी बदतर है - यह एक वास्तुशिल्प अपराध है।

एक अच्छी वास्तुकला के साथ, आपको साझा रूप से साझा करने में सक्षम होना चाहिए, दर्द रहित और जल्दी से सब कुछ को बदलने के लिए जो परीक्षण संस्करणों के साथ share_ptr से संबंधित नहीं है। उदाहरण के लिए, आवंटनकर्ता का एक परीक्षण संस्करण। या बढ़ावा के बारे में भूल जाओ। मान लीजिए कि आप एक xml / html पार्सर लिखते हैं। आपको तार के साथ काम करने और पार्सर के लिए फाइलों के साथ काम करने की आवश्यकता है। और अगर हम एक ऐसे आदर्श आर्किटेक्चर के बारे में बात कर रहे हैं जो किसी विशेष उत्पादन / सॉफ्टवेयर कंपनी की जरूरतों से बंधा नहीं है, तो एक आदर्श आर्किटेक्चर वाले पार्सर के लिए हमें std :: istream, std :: file_system, std :: string और stringcode के साथ हार्डकोड सर्च ऑपरेशन का उपयोग करने का अधिकार नहीं है। पार्सर में। हमें एक स्ट्रीम इंटरफ़ेस प्रदान करना चाहिए, फ़ाइल संचालन के लिए एक इंटरफ़ेस (शायद उप-इंटरफ़ेस में विभाजित है, लेकिन उप-केंद्रों तक पहुंच अभी भी फ़ाइल संचालन मॉड्यूल के इंटरफ़ेस के माध्यम से करना होगा), स्ट्रिंग्स के साथ काम करने के लिए एक इंटरफ़ेस, एक आवंटन इंटरफ़ेस और आदर्श रूप से लाइन के लिए भी एक इंटरफ़ेस। नतीजतन, हम दर्द रहित रूप से उन सभी चीज़ों को बदल सकते हैं जो टेस्ट ब्लैंक के साथ पार्सिंग से संबंधित नहीं हैं, या आवंटनकर्ता का एक परीक्षण संस्करण सम्मिलित करें / अतिरिक्त चेक के साथ फ़ाइलों / स्ट्रिंग खोज के साथ काम कर रहा है। और समाधान की बहुमुखी प्रतिभा बढ़ेगी - कल, धारा के इंटरफ़ेस के तहत एक फ़ाइल नहीं होगी, लेकिन इंटरनेट पर कहीं एक साइट, और कोई भी इसे नोटिस नहीं करेगा। आप क्यूटी के साथ मानक पुस्तकालय को बदल सकते हैं, और फिर विज़ुअल सी ++ पर स्विच कर सकते हैं, और फिर केवल लिनक्स चीजों का उपयोग करना शुरू कर सकते हैं - और परिवर्तन न्यूनतम होंगे। एक बिगाड़ने वाले के रूप में, मेरा कहना है कि इस दृष्टिकोण के साथ, मूल्य सवाल पूरी वृद्धि में आता है - मानक पुस्तकालय के तत्वों सहित इंटरफेस के साथ सब कुछ कवर करने के लिए, महंगा है, लेकिन यह एक लक्ष्य नहीं है, बल्कि एक समाधान है।

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

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

हम अच्छी वास्तुकला की मुख्य विशेषताओं को इंगित करते हैं, जिसमें ऊपर बताए गए बिंदु, बिंदु-दर-बिंदु शामिल हैं।

चलो "मॉड्यूल" शब्द को परिभाषित करते हैं। एक मॉड्यूल तार्किक रूप से संबंधित कार्यक्षमता का योग है। उदाहरण के लिए, स्ट्रीम या फ़ाइल कार्य, या HTML पार्सर के साथ काम करें।

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

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

बेशक, हम यह पता लगाएंगे कि कम कीमत के लिए यह सब कैसे जल्दी से हासिल किया जाए, लेकिन मैं एक और समस्या पर ध्यान आकर्षित करना चाहूंगा, जिसका समाधान हमारे लिए एक बोनस होगा - प्लेटफ़ॉर्म-निर्भर मापदंडों का स्थानांतरण। उदाहरण के लिए, यदि आपको एंड्रॉइड और विंडोज पर समान रूप से काम करने वाले कोड बनाने की आवश्यकता है, तो अलग-अलग मॉड्यूल के लिए प्लेटफ़ॉर्म-निर्भर एल्गोरिदम आवंटित करना तर्कसंगत होगा। इस स्थिति में, शायद, एंड्रॉइड के कार्यान्वयन के लिए जावा (jni) वातावरण, JNIEnv *, और संभवतः जावा ऑब्जेक्ट्स के एक जोड़े की आवश्यकता हो सकती है। और विंडोज पर कार्यान्वयन के लिए कार्यक्रम के एक काम करने वाले फ़ोल्डर की आवश्यकता हो सकती है (जो एंड्रॉइड पर सिस्टम से अनुरोध किया जा सकता है, जिसमें JNIEnv * हो सकता है)। चाल यह है कि विंडोज संदर्भ में समान JNIEnv * मौजूद नहीं है, इसलिए एक टाइप किए गए यूनियन या इसके c ++ विकल्प का भी std :: variant असंभव है। आप निश्चित रूप से शून्य * वेक्टर या एसटीडी :: किसी भी वेक्टर को एक पैरामीटर के रूप में उपयोग कर सकते हैं, लेकिन ईमानदारी से, यह एक atypical बैसाखी है। Atypical - क्योंकि यह c ++ का मुख्य लाभ, मजबूत टाइपिंग को अस्वीकार करता है। और यह सार्स की तुलना में अधिक खतरनाक है।

आगे हम विश्लेषण करेंगे कि इस मुद्दे को कड़ाई से कैसे हल किया जाए।

भाग 2. मैजिक बुलेट और उनके मूल्य टैग

तो, मान लें कि हमारे पास बड़ी मात्रा में कोड है जिसे स्क्रैच से लिखना होगा, और परिणाम एक बहुत बड़ी परियोजना होगी।

हमारे द्वारा निर्धारित सिद्धांतों के अनुसार इसे कैसे इकट्ठा किया जा सकता है?

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

किसी को संदेह हो सकता है, और अपने आप में होगा। चलो एक मोटा अनुमान लगाते हैं। बता दें कि मध्यम वर्ग में 3-5 सदस्य और 20 कार्य और 3 निर्माणकर्ता होते हैं। साथ ही हमारे सदस्यों तक पहुंच के लिए 6-10 गेटर्स और सेटर (म्यूटेटर)। कक्षा में कुल लगभग 40 इकाइयाँ। एक विशिष्ट परियोजना में, प्रत्येक "केंद्र" वर्ग को औसतन पाँच कार्यों तक पहुँच की आवश्यकता होती है, न कि एक केंद्र 3 की। उदाहरण के लिए, बहुत से वर्गों को एक आवंटनकर्ता, फाइल सिस्टम, तार के साथ काम करने, धाराओं के साथ काम करने और डेटाबेस तक पहुँच की आवश्यकता होती है।

प्रत्येक रणनीति / इंटरफ़ेस के लिए std::shared_ptr<CreateStreamStrategy> m_create_stream; एक सदस्य की आवश्यकता होगी std::shared_ptr<CreateStreamStrategy> m_create_stream; । दो उत्परिवर्ती, तीन निर्माणकर्ताओं में से प्रत्येक में प्रारंभिक प्रारंभ। हमारी कक्षा के आरंभ में कहीं न कहीं, आपको myclass->SetCreateStreamStrategy( my_create_stream_strategy ) कुछ समय के लिए, 8 यूनिट की कुल इंटरफ़ेस / रणनीति के लिए कॉल करना होगा, और चूंकि हमारे पास इनमें से पाँच हैं, इसलिए 40 इकाइयाँ होंगी। यही है, हमने स्रोत वर्ग को दो बार बोझिल बना दिया। और सादगी का नुकसान अनिवार्य रूप से पठनीयता को प्रभावित करेगा, और कहीं और डिबगिंग की प्रक्रिया में, और डेढ़ बार, इस तथ्य के बावजूद कि कुछ भी नहीं लगता है कि अनिवार्य रूप से बदल गया है।

तो सवाल है। कैसे भी करें, लेकिन न्यूनतम मूल्य पर? पहली बात जो दिमाग में आती है वह है अलेक्जेंड्रेस्क्यू और लोकी लाइब्रेरी की शैली में, टेम्प्लेट पर स्थैतिक परिमाणीकरण।

हम शैली में एक वर्ग लिख रहे हैं

 template < struct Traits > class MyClass { public: void DoMainTaskFunction() { ... MyStream stream = Traits::streamwork::Open( stream_name ); ... } };

इस निर्णय के सभी वास्तु फायदे हैं जिन्हें हमने पहले भाग में पहचाना था। लेकिन इसके कई नुकसान भी हैं।

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

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

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

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

भाग तीन प्रस्तावित समाधान और कोड इस समाधान के लिए एन्कोड किया गया

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

एक प्रकार - एक वस्तु। लेकिन प्रकारों की संख्या सीमित नहीं है! इसलिए, आप एक पैरामीटर के रूप में इस तरह के एक वर्ग को पारित कर सकते हैं।

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

हम तीन मूल कार्य करेंगे: क्रिएट, गेट एंड हस। तदनुसार, एक तत्व की उपस्थिति का निर्माण, रसीद और सत्यापन।

 /// @brief    .      ,    ///           /// class TypedSet { public: template <class TypedElement> void Create( const std::shared_ptr<TypedElement> & value ); template <class TypedElement> std::shared_ptr<TypedElement> Get() const; template <class TypedElement> bool Has() const; size_t GetSize() const { return storage_.size(); } protected: typedef std::map< size_t, std::shared_ptr<void> > Storage; Storage const & storage() const { return storage_; } Storage & get_storage() { return storage_; } private: Storage storage_; }; template <class TypedElement> void TypedSet::Create( const std::shared_ptr<TypedElement> & value ) { size_t hash = typeid(TypedElement).hash_code(); if ( storage().count( hash ) > 0 ) { LogError( "Access Violation" ); return; } std::shared_ptr<void> to_add ( value ); get_storage().insert( std::pair( typeid(TypedElement).hash_code(), to_add ) ); } template <class TypedElement> bool TypedSet::Has() const { size_t hash = typeid(TypedElement).hash_code(); return storage().count( hash ) > 0; } template <class TypedElement> std::shared_ptr<TypedElement> TypedSet::Get() const { size_t hash = typeid(TypedElement).hash_code(); if ( storage().count( hash ) > 0 ) { std::shared_ptr<void> ret( storage().at(hash) ); return std::static_pointer_cast<TypedElement>( ret ); } else { LogError( "Access Violation" ); return std::shared_ptr<TypedElement> (); } }

वैसे, मैंने क्यूटी में लिखने वाले सहयोगियों से एक वैकल्पिक समाधान देखा। वहां, वांछित इंटरफ़ेस तक पहुंच एक सिंगलटन के माध्यम से की गई थी, जिसे वांछित इंटरफ़ेस "मैप" किया गया था, जिसे वर्न में पैक किया गया था, एक टेक्स्ट लाइन (!!!) के माध्यम से, और इस विकल्प को चुनने के बाद, परिणाम का उपयोग किया जा सकता है।

 GlobalConfigurator()["FileSystem"].Get().As<FileSystem>()

यह निश्चित रूप से काम करता है, लेकिन लंबाई और आगे की हैशिंग को गिनने का ओवरहेड मेरी आशावादी आत्मा के लिए कुछ डरावना है। यहां, ओवरहेड शून्य है, क्योंकि वांछित इंटरफ़ेस का चुनाव संकलन समय पर किया जाता है।

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

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

 class StrategiesSet { public: template <class Strategy> void Create( const std::shared_ptr<Strategy> & value ); template <class Strategy> std::shared_ptr<Strategy> Get(); template <class Strategy> void CreateParamsSet(); template <class Strategy> std::shared_ptr<TypedSet> GetParamsSet(); template <class Strategy, class ParamType> void CreateParam( const std::shared_ptr<ParamType> & value ); template <class Strategy, class ParamType> std::shared_ptr<ParamType> GetParam(); protected: TypedSet const & strategies() const { return strategies_; } TypedSet & get_strategies() { return strategies_; } TypedSet const & params() const { return params_; } TypedSet & get_params() { return params_; } template <class Type> struct ParamHolder { ParamHolder( ) : param_ptr( std::make_shared<TypedSet>() ) {} std::shared_ptr<TypedSet> param_ptr; }; private: TypedSet strategies_; TypedSet params_; }; template <class Strategy> void StrategiesSet::Create( const std::shared_ptr<Strategy> & value ) { get_strategies().Create<Strategy>( value ); } template <class Strategy> std::shared_ptr<Strategy> StrategiesSet::Get() { return get_strategies().Get<Strategy>(); } template <class Strategy> void StrategiesSet::CreateParamsSet( ) { typedef ParamHolder<Strategy> Holder; std::shared_ptr< Holder > ptr = std::make_shared< Holder >( ); ptr->param_ptr = std::make_shared< TypedSet >(); get_params().Create< Holder >( ptr ); } template <class Strategy> std::shared_ptr<TypedSet> StrategiesSet::GetParamsSet() { typedef ParamHolder<Strategy> Holder; if ( get_params().Has< Holder >() ) { return get_params().Get< Holder >()->param_ptr; } else { LogError("StrategiesSet::GetParamsSet : get unexisting!!!"); return std::shared_ptr<TypedSet>(); } } template <class Strategy, class ParamType> void StrategiesSet::CreateParam( const std::shared_ptr<ParamType> & value ) { typedef ParamHolder<Strategy> Holder; if ( !params().Has<Holder>() ) CreateParamsSet<Strategy>(); if ( params().Has<Holder>() ) { std::shared_ptr<TypedSet> params_set = GetParamsSet<Strategy>(); params_set->Create<ParamType>( value ); } else { LogError( "Param creating error: Access Violation" ); } } template <class Strategy, class ParamType> std::shared_ptr<ParamType> StrategiesSet::GetParam() { typedef ParamHolder<Strategy> Holder; if ( params().Has<Holder>() ) { return GetParamsSet<Strategy>()->template Get<ParamType>(); //   template          .    . } else { LogError( "Access Violation" ); return std::shared_ptr<ParamType> (); } }

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

खैर, और एक छोटा और (अभी तक) अत्यधिक सरलीकृत उपयोग मामला। मुझे आशा है कि आप टिप्पणियों में मुझे सुझाव देंगे कि आप एक सरल उदाहरण के रूप में क्या देखना चाहते हैं, और मैं लेख को एक छोटा सा उन्नयन बनाऊंगा। जैसा कि लोकप्रिय प्रोग्रामिंग ज्ञान कहता है, "जितनी जल्दी हो सके रिलीज करें और रिलीज के बाद प्रतिक्रिया का उपयोग करके सुधार करें।"

 class Interface1 { public: virtual void Fun() { printf("\niface1\n");} virtual ~Interface1() {} }; class Interface2 { public: virtual void Fun() { printf("\niface2\n");} virtual ~Interface2() {} }; class Interface3 { public: virtual void Fun() { printf("\niface3\n");} virtual ~Interface3() {} }; class Implementation1 : public Interface1 { public: virtual void Fun() override { printf("\nimpl1\n");} }; class Implementation2 : public Interface2 { public: virtual void Fun() override { printf("\nimpl2\n");} }; class PrintParams { public: virtual ~PrintParams() {} virtual std::string GetOs() = 0; }; class PrintParamsUbuntu : public PrintParams { public: virtual std::string GetOs() override { return "Ubuntu"; } }; class PrintParamsWindows : public PrintParams { public: virtual std::string GetOs() override { return "Windows"; } }; class PrintStrategy { public: virtual ~PrintStrategy() {} virtual void operator() ( const TypedSet& params, const std::string & str ) = 0; }; class PrintWithOsStrategy : public PrintStrategy { public: virtual void operator()( const TypedSet& params, const std::string & str ) override { auto os = params.Get< PrintParams >()->GetOs(); printf(" Printing: %s (OS=%s)", str.c_str(), os.c_str() ); } }; void TestTypedSet() { using namespace std; TypedSet a; a.Create<Interface1>( make_shared<Implementation1>() ); a.Create<Interface2>( make_shared<Implementation2>() ); a.Get<Interface1>()->Fun(); a.Get<Interface2>()->Fun(); Log("Double creation:"); a.Create<Interface1>( make_shared<Implementation1>() ); Log("Get unexisting:"); a.Get<Interface3>(); } void TestStrategiesSet() { using namespace std; StrategiesSet printing; printing.Create< PrintStrategy >( make_shared<PrintWithOsStrategy>() ); printing.CreateParam< PrintStrategy, PrintParams >( make_shared<PrintParamsWindows>() ); auto print_strategy_ptr = printing.Get< PrintStrategy >(); auto & print_strategy = *print_strategy_ptr; auto & print_params = *printing.GetParamsSet< PrintStrategy >(); print_strategy( print_params, "Done!" ); } int main() { TestTypedSet(); TestStrategiesSet(); return 0; }

सारांश

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

उदाहरण और उपकरण वर्गों के लिए कोड यहां पाया जा सकता है।

Upd। 11/13/2019 से
वास्तव में, यहां दिखाया गया कोड पठनीयता के लिए एक सरल उदाहरण है। तथ्य यह है कि टाइपिड () हैश_कोड आधुनिक कंपाइलरों में धीरे-धीरे और अक्षम रूप से लागू किया जाता है। इसका उपयोग अर्थ को बहुत मारता है। इसके अलावा, जैसा कि सम्मानित किया गया 0xd34df00d ने सुझाव दिया , मानक हैशकोड द्वारा प्रकारों को अलग करने की क्षमता की गारंटी नहीं देता है (व्यवहार में, यह दृष्टिकोण हालांकि काम करता है)। लेकिन उदाहरण अच्छी तरह से पढ़ा है। मैंने टाइप किए बिना टाइप किए गए टाइप किए गए ()। Hash_code (), इसके अलावा, प्रतिस्थापित सरणी के साथ नक्शा (लेकिन #if में एक अंक बदलकर जल्दी से नक्शे से सरणी में स्विच करने और इसके विपरीत करने की क्षमता के साथ) को फिर से लिखा। यह अधिक कठिन हो गया, लेकिन व्यावहारिक उपयोग के लिए अधिक दिलचस्प है।
कोलीरू में

 namespace metatype { struct Counter { size_t GetAndIncrease() { return counter_++; } private: size_t static inline counter_ = 1; }; template <typename Type> struct HashGetterBody { HashGetterBody() : hash_( counter_.GetAndIncrease() ) { } size_t GetHash() { return hash_; } private: Counter counter_; size_t hash_; }; template <typename Type> struct HashGetter { size_t GetHash() {return hasher_.GetHash(); } private: static inline HashGetterBody<Type> hasher_; }; } // namespace metatype template <typename Type> size_t GetTypeHash() { return metatype::HashGetter<Type>().GetHash(); } namespace details { #if 1 //   ,        () class TypedSetStorage { public: static inline const constexpr size_t kMaxTypes = 100; typedef std::array< std::shared_ptr<void>, kMaxTypes > Storage; void Set( size_t hash_index, const std::shared_ptr<void> & value ) { ++size_; assert( hash_index < kMaxTypes ); // too many types data_[hash_index] = value; } std::shared_ptr<void> & Get( size_t hash_index ) { assert( hash_index < kMaxTypes ); return data_[hash_index]; } const std::shared_ptr<void> & Get( size_t hash_index ) const { if ( hash_index >= kMaxTypes ) return empty_ptr_; return data_[hash_index]; } bool Has( size_t hash_index ) const { if ( hash_index >= kMaxTypes ) return 0; return (bool)data_[hash_index]; } size_t GetSize() const { return size_; } private: Storage data_; size_t size_ = 0; static const inline std::shared_ptr<void> empty_ptr_; }; #else //    ,        (std::map) class TypedSetStorage { public: typedef std::map< size_t, std::shared_ptr<void> > Storage; void Set( size_t hash_index, const std::shared_ptr<void> & value ) { data_[hash_index] = value; } std::shared_ptr<void> & Get( size_t hash_index ) { return data_[hash_index]; } const std::shared_ptr<void> & Get( size_t hash_index ) const { return data_.at(hash_index); } bool Has( size_t hash_index ) const { return data_.count(hash_index) > 0; } size_t GetSize() const { return data_.size(); } private: Storage data_; }; #endif } // namespace details /// @brief    .      ,    ///           /// class TypedSet { public: template <class TypedElement> void Create( const std::shared_ptr<TypedElement> & value ); template <class TypedElement> std::shared_ptr<TypedElement> Get() const; template <class TypedElement> bool Has() const; size_t GetSize() const { return storage_.GetSize(); } protected: typedef details::TypedSetStorage Storage; Storage const & storage() const { return storage_; } Storage & get_storage() { return storage_; } private: Storage storage_; }; template <class TypedElement> void TypedSet::Create( const std::shared_ptr<TypedElement> & value ) { size_t hash = GetTypeHash<TypedElement>(); if ( storage().Has( hash ) ) { LogError( "Access Violation" ); return; } std::shared_ptr<void> to_add ( value ); get_storage().Set( hash, to_add ); } template <class TypedElement> bool TypedSet::Has() const { size_t hash = GetTypeHash<TypedElement>(); return storage().Has( hash ); } template <class TypedElement> std::shared_ptr<TypedElement> TypedSet::Get() const { size_t hash = GetTypeHash<TypedElement>(); if ( storage().Has( hash ) ) { std::shared_ptr<void> ret( storage().Get( hash ) ); return std::static_pointer_cast<TypedElement>( ret ); } else { LogError( "Access Violation" ); return std::shared_ptr<TypedElement> (); } }

यहां पहुंच को रैखिक समय में किया जाता है, टाइप हैश को मुख्य () लॉन्च होने से पहले गिना जाता है, नुकसान केवल सत्यापन जांच के लिए होता है, जिसे वांछित होने पर फेंक दिया जा सकता है।

भाग 1. एक वैक्यूम में गोलाकार वास्तुकला

भाग 2. मैजिक बुलेट और उनके मूल्य टैग

भाग तीन प्रस्तावित समाधान और कोड इस समाधान के लिए एन्कोड किया गया

सारांश

More articles: