हमारे क्लाइंट को अपग्रेड करना चुनना है। इसलिए, मेरी टीम को सचमुच हमारे सॉफ्टवेयर उत्पाद के दर्जनों संस्करणों को बनाए रखना और समर्थन करना है। जैसा कि आप कल्पना कर सकते हैं कि परिणामस्वरूप बहुत सारे ब्रांचिंग और विलय के रूप में गर्म फिक्स और सर्विस पैक को इन सभी स्वादों में प्रचारित किया जाना है। मैं स्थिति से खुश नहीं हूँ। स्पष्ट समाधान हमारे उत्पाद के इतने सारे अलग-अलग संस्करणों को बनाए रखने के लिए नहीं है, लेकिन यह स्पष्ट समाधान मेरे लिए उपलब्ध नहीं है। इसलिए, मैं टीम के रखरखाव के काम को कम करने के लिए रचनात्मक विकल्पों की खोज कर रहा हूं। मैं फीचर टॉगलिंग और आईओसी के मिश्रण का उपयोग अपने सॉफ्टवेयर उत्पाद के संस्करणों की संख्या को लागू करने के तरीके के रूप में करने पर विचार कर रहा हूं। विचार यह है कि मैं अपने उत्पाद के लिए एक कोड बेस का उपयोग कर सकता हूं और कॉन्फ़िगरेशन प्रबंधन के माध्यम से व्यवहार और सुविधाओं का प्रबंधन कर सकता हूं। यह कई शाखाओं में कोड प्रसारित करने के बदले में होगा। क्या यह एक उचित दृष्टिकोण है या क्या मैं सिर्फ एक समस्या के लिए एक समस्या का व्यापार कर रहा हूं?ब्रांचिंग कोड के बदले फ़ीचर टॉगलिंग और आईओसी का उपयोग करना - अच्छा या बुरा विचार?
उत्तर
यह उचित लगता है, इस तरह से मैं एक ग्रीनफील्ड पर्यावरण में ऐसी समस्या का समाधान करूंगा।
चलो यह हालांकि फोन नहीं एक फ़ीचर टॉगल,। जैसा कि नाम का तात्पर्य है, Feature Toggle स्विच चालू/बंद है, जो आपको आवश्यक नहीं हो सकता है।
कभी-कभी, अपग्रेड में भी शामिल है मौजूदा सुविधाओं में व्यवहार बदल गया। इसका तात्पर्य है कि आपको शायद स्विच चालू/बंद से अधिक परिष्कृत की आवश्यकता होगी।
Strategy pattern व्यवहार में भिन्नता मॉडलिंग का एक अधिक लचीला तरीका है। प्रत्येक रणनीति किसी विशेष व्यवहार के किसी विशेष संस्करण का प्रतिनिधित्व कर सकती है, और यदि आप व्यवहार को बिल्कुल नहीं चाहते हैं, तो आप Null Object कार्यान्वयन प्रदान कर सकते हैं। दूसरे शब्दों में, फ़ीचर टॉगल को एक रणनीति के साथ कार्यान्वित किया जा सकता है।
आप निर्भरता इंजेक्शन का उपयोग करके अपने अनुप्रयोग कर्नेल में रणनीतियां इंजेक्ट कर सकते हैं, और आप कॉन्फ़िगरेशन सिस्टम के माध्यम से कॉन्फ़िगर करने योग्य रणनीतियों की पसंद कर सकते हैं। अधिकांश डी कंटेनर मैंने सुना है (.NET और जावा पर) फ़ाइल-आधारित कॉन्फ़िगरेशन का समर्थन करते हैं।
यह अनिवार्य रूप से ऐड-इन आर्किटेक्चर का वर्णन करता है।
अब, यहां तक कि एक ग्रीनफील्ड एप्लिकेशन के लिए, यह खींचने के लिए कोई आसान काम नहीं है। यदि आपके पास हेडलेस सिस्टम है, तो यह हार्ड नहीं है, लेकिन एक बार आपके पास यूआई शामिल होने के बाद, आपको यह एहसास हो जाएगा कि आपको यूआई आर्किटेक्चर को कंप्यूटरीकृत करने की आवश्यकता होगी, ताकि आप रणनीतियों के माध्यम से यूआई तत्वों को प्लग कर सकें ।
एक दशक पुराने कोड बेस पर, यह वही होगा जो मैं कम से कम कहने के लिए 'दिलचस्प चुनौती' कहूंगा।
उचित लगता है। आप एक कोडबेस के लिए कई शाखाओं का व्यापार करेंगे, सुविधाओं को चालू और बंद कर देंगे। सैद्धांतिक रूप से, आप w/कॉन्फ़िगरेशन को चालू या बंद कर सकते हैं। यदि आपको वास्तव में चलाने के लिए अलग-अलग कोड की आवश्यकता है, तो आप आईओसी कंटेनर डब्ल्यू/विभिन्न कोड कार्यान्वयन का उपयोग कर सकते हैं। यदि आप अपने प्रश्न में अधिक विशिष्ट थे, तो आपके प्रश्न का उत्तर देना आसान होगा, जिससे आपकी वर्तमान शैली बनाम एक प्रस्तावित शैली का उदाहरण दिया जा सके। –
धन्यवाद राउल, आपने इसे अच्छी तरह से समझाया और आईओसी को अलग-अलग लागू करने से निपटने के लिए लीवरेज किया जो वास्तव में मेरे मन में था। मुझे यकीन नहीं है कि शैलियों के बारे में आपके प्रश्न का उत्तर कैसे दिया जाए। आवेदन एक दशक से अधिक पुराना है, इसलिए यह किसी एकल शैली को प्रतिबिंबित नहीं करता है। मैं शायद उपरोक्त रणनीति को पुन: संगठित घटकों के लिए लागू करूंगा। ऐसा लगता है कि प्रस्तावित रणनीति किसी भी लाल झंडे को उठा रही है। -- धन्यवाद। –