जेनरेट कोड बदलना या विरासत का उपयोग करना?

Question

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

अन्य कोड पीढ़ी के ढांचे के साथ खराब अनुभवों के आधार पर डिजाइन निर्णय फिर से पीढ़ी की समस्याओं को हल करने के लिए किया गया था।

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

Answer 1

लेकिन आपके अनुभव क्या हैं?

मैंने दो अलग-अलग परियोजनाओं को लागू किया है, जिनमें से दोनों 50 या अधिक मॉडल वर्गों के साथ मॉडल शामिल हैं, और दोनों मामलों में मॉडल परियोजना के पूरे जीवनकाल में विकसित हुए; i.e. मॉडल परिवर्तनों के बहुत सारे। दोनों मामलों में, मैंने जेनरेट किए गए कोड को आम तौर पर गणना किए गए विशेषताओं, सत्यापन और संपादकों को विभिन्न तरीकों से अनुकूलित करने के लिए संशोधित किया।

कितनी अच्छी तरह से ईएमएफ उत्पन्न कोड में मैनुअल कोड में परिवर्तन करता है?

यह अच्छी तरह से काम करता है। कभी-कभी जेनरेटर कोड उत्पन्न करता है जो कुछ मॉडल परिवर्तन के कारण संकलित नहीं होता है, लेकिन फिक्स आमतौर पर सरल होते हैं; जैसे जावा वर्गों/इंटरफेस, मृत आयात, आदि

को हटाने क्या तुमने कभी एक बिंदु है जहां आप मैन्युअल लिखे कोड खो करने के लिए आया था?

केवल कभी-कभी कभी-कभी। एक बार जब आप "जेनरेट" मार्कर टिप्पणी को हटाना भूल जाते हैं और जब आप मॉडल को पुन: उत्पन्न करते हैं तो आपकी विधि को गिरफ्तार किया जाता है।

(मैं अगर यह एक प्रमुख चिंता का विषय था आप परिवर्तनों में विलय से पहले ईएमएफ जनरेटर स्रोत पेड़ को संशोधित कर सकता है हमेशा बैकअप लगता है।)

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

क्या कोड कभी भी एक गैर-रखरखाव स्थिति में आता है?

नहीं। कभी नहीं।

---

पढ़ना consta_a का जवाब मुझे याद दिलाता है कि मैं हमेशा संस्करण नियंत्रण में मेरी उत्पन्न ईएमएफ वर्गों की जाँच की। लंबी अवधि में हाथों के संपादन खोने से बचने का यह सबसे अच्छा तरीका है।

Answer 2

मैं स्टीफन सी उत्तर की पुष्टि करता हूं: हमारे मामले में हम अपने मॉडल में लगभग 120 कक्षाएं संभालते हैं, जिसका अर्थ है 120 इंटरफेस + 120 कार्यान्वयन कक्षाएं + अनगिनत संपादन कक्षाएं और पुनर्जन्म काफी अच्छी तरह से चला जाता है (अगर हम आसानी से जेनरेट किए गए वर्गों को स्वरूपित कर सकते हैं जैसा कि हम चाहते हैं (^ _ ^))

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