मुझे एक प्रोजेक्ट मिला है। इस परियोजना में मैंने इसे एक फीचर जोड़ने के लिए रीफ़ैक्टर करने की इच्छा की, और मैंने फ़ीचर को जोड़ने के लिए प्रोजेक्ट को फिर से सक्रिय कर दिया।
समस्या यह है कि जब मैं किया गया था, यह पता चला कि मुझे इसे समायोजित करने के लिए एक मामूली इंटरफ़ेस परिवर्तन करने की आवश्यकता थी। इसलिए मैंने बदलाव किया। और फिर उपभोग करने वाले वर्ग को नए के संदर्भ में अपने वर्तमान इंटरफ़ेस के साथ लागू नहीं किया जा सकता है, इसलिए इसे एक नए इंटरफ़ेस की भी आवश्यकता है। अब यह तीन महीने बाद है, और मुझे लगभग असंबंधित समस्याओं को ठीक करना है, और मैं उन मुद्दों को हल कर रहा हूं जो अभी से एक वर्ष के लिए सड़क पर थे या बस सूचीबद्ध किए गए क्योंकि कठिनाई के कारण बात ठीक हो जाएगी। फिर।
मैं भविष्य में इस तरह के कैस्केडिंग रिफैक्टरिंग से कैसे बच सकता हूं? क्या यह सिर्फ मेरी पिछली कक्षाओं का एक लक्षण है जो एक दूसरे पर बहुत कसकर निर्भर करता है?
संक्षिप्त संपादित करें: इस मामले में, refactor था के बाद से refactor कोड का एक विशेष खंड के तानाना वृद्धि हुई है और कुछ युग्मन कम, सुविधा। इसका मतलब यह था कि बाहरी डेवलपर्स अधिक कर सकते हैं, जो कि वह सुविधा थी जिसे मैं वितरित करना चाहता था। तो मूल प्रतिक्षेपक को ही कार्यात्मक परिवर्तन नहीं करना चाहिए था।
बड़ा संपादन जो मैंने पांच दिन पहले वादा किया था:
इससे पहले कि मैं इस रिफ्लेक्टर को शुरू करता, मेरे पास एक ऐसी प्रणाली थी जहां मेरा एक इंटरफ़ेस था, लेकिन कार्यान्वयन में, मैंने बस dynamic_castउन सभी संभावित कार्यान्वयनों के माध्यम से जो मैंने शिप किया था। इसका स्पष्ट रूप से मतलब था कि आप इंटरफ़ेस से केवल एक चीज़ के लिए विरासत में प्राप्त नहीं कर सकते, और दूसरी बात, कि इस इंटरफ़ेस को लागू करने के लिए कार्यान्वयन पहुंच के बिना किसी के लिए भी असंभव होगा। इसलिए मैंने फैसला किया कि मैं इस मुद्दे को ठीक करना चाहता हूं और सार्वजनिक खपत के लिए इंटरफ़ेस को खोलना चाहता हूं ताकि कोई भी इसे लागू कर सके और इंटरफ़ेस को लागू करने के लिए पूरे अनुबंध की आवश्यकता थी- जाहिर है एक सुधार।
जब मैं उन सभी जगहों पर आग लगा रहा था और मार रहा था, जो मैंने किया था, तो मुझे एक जगह मिली जो एक विशेष समस्या साबित हुई। यह उन सभी विभिन्न व्युत्पन्न वर्गों और डुप्लिकेट किए गए कार्यक्षमता के कार्यान्वयन विवरण पर निर्भर करता है जो पहले से ही लागू किया गया था लेकिन कहीं और बेहतर था। इसके बजाय इसे सार्वजनिक इंटरफ़ेस के रूप में लागू किया जा सकता था और उस कार्यक्षमता के मौजूदा कार्यान्वयन का फिर से उपयोग किया जा सकता था। मुझे पता चला कि इसे सही ढंग से काम करने के लिए संदर्भ के एक विशेष टुकड़े की आवश्यकता थी। मोटे तौर पर, पिछले कार्यान्वयन को कॉलिंग थोड़े पसंद आई
for(auto&& a : as) {
f(a);
}
हालाँकि, इस संदर्भ को प्राप्त करने के लिए, मुझे इसे कुछ और चीजों में बदलने की आवश्यकता थी
std::vector<Context> contexts;
for(auto&& a : as)
contexts.push_back(g(a));
do_thing_now_we_have_contexts();
for(auto&& con : contexts)
f(con);
इसका मतलब यह है कि सभी ऑपरेशनों के लिए जो एक हिस्सा हुआ करते थे f, उनमें से कुछ को gबिना किसी संदर्भ के संचालित होने वाले नए फ़ंक्शन का एक हिस्सा बनाने की आवश्यकता होती है, और उनमें से कुछ को अब आस्थगित के एक हिस्से से बनाने की आवश्यकता होती है f। लेकिन सभी तरीकों को fइस संदर्भ की आवश्यकता नहीं है या नहीं चाहिए- उनमें से कुछ को एक अलग संदर्भ की आवश्यकता है जो वे अलग-अलग साधनों के माध्यम से प्राप्त करते हैं। तो हर उस चीज के लिए fजो कॉलिंग को समाप्त करती है (जो कि मोटे तौर पर, बहुत ज्यादा सब कुछ बोलती है ), मुझे यह निर्धारित करना था कि क्या, यदि कोई हो, संदर्भ की जरूरत है, तो वे इसे कहां से प्राप्त करें, और उन्हें पुराने fसे नए fऔर नए में कैसे विभाजित करें g।
और इसी तरह मैंने अब मैं जहां हूं, उसे खत्म कर दिया। एकमात्र कारण जो मैं जाता रहा, क्योंकि मुझे अन्य कारणों से इस रीफैक्टरिंग की आवश्यकता थी।