ईश्वर वस्तुओं को तोड़ने के लिए इंटरफेस विरासत?

Question

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

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

बस इस वर्ग को विभाजित करना अभी सवाल से बाहर है क्योंकि सचमुच सैकड़ों हैं यदि इस वर्ग के हजारों संदर्भ नहीं हैं।

क्योंकि मेरे पास एक इंटरफ़ेस है (और इंटरफ़ेस का उपयोग करने के लिए लगभग सभी कोड को दोबारा प्रतिक्रिया दी गई है) हालांकि, मेरे पास एक दिलचस्प विचार था। क्या होगा यदि मैंने ISession इंटरफ़ेस को अन्य इंटरफेस से प्राप्त किया है।

उदाहरण के लिए

, अगर हम कुछ इस तरह था:

interface IBar 
{ 
    string Baz{get;set;} 
} 

interface IFoo 
{ 
    string Biz{get;set;} 
} 

interface ISession: IFoo, IBar 
{ 
} 

इस तरह, मौजूदा कोड ISession का उपयोग कर अद्यतन करने की नहीं होती, और न ही वास्तविक क्रियान्वयन अद्यतन किया जाना है। लेकिन, नए कोड में हम लिखते हैं और रिफैक्टर करते हैं, हम अधिक दानेदार IFoo या IBar इंटरफेस का उपयोग कर सकते हैं, लेकिन एक ISession में पास कर सकते हैं।

और अंत में, मैं यह देखने के रूप में शायद यह आसान अंत में वास्तविक ISession और सत्र भगवान इंटरफ़ेस/वस्तु

अब आप को तोड़ने के लिए बना रही है। क्या यह इन ईश्वर वस्तुओं के खिलाफ परीक्षण करने और अंततः उन्हें तोड़ने का एक अच्छा तरीका है? क्या यह एक दस्तावेजी दृष्टिकोण और/या डिजाइन पैटर्न है? क्या आपने कभी ऐसा कुछ किया है?

Answer 1

मेरे दृष्टिकोण से यह अच्छा और सही दृष्टिकोण है। बाद में आप /IBar के रूप में ISession के बजाय अधिक विशिष्ट सेवा उदाहरणों को इंजेक्ट कर सकते हैं, मैं कहूंगा कि यह एक ईश्वर वर्ग से कई विशिष्ट सेवाओं तक कक्षाओं को निकालने के लिए आगे प्रतिक्रिया करने से पहले एक अच्छा मध्यवर्ती कदम है।

कुछ पेशेवरों मैं देख रहा हूँ:

पहला चरण: निकालने इंटरफेस

• एक सुपर (देवता) वर्ग प्रकार इंटरफेस
• कोड कम मिलकर हो जाता है से निकाला गया है के बाद से एकल समारोह पर निर्भर करता है जिम्मेदार इंटरफेस (सेवाएं)
• आपके पास आगे बढ़ने और एक ईश्वर वर्ग को कई सेवाओं में विभाजित करने के लिए जमीन है, बिना किसी बड़े पैमाने पर रिफैक्टरिंग सिकने सबथिग पहले से ही इंटरफेस पर निर्भर करता है एपीआई

दूसरा चरण: मन में Single Responsibility principle रखने के साथ कई छोटे सेवाओं में एक देवता वर्ग विभाजित

तीसरे चरण: तो एक साथ चारों ओर नहीं बल्कि सभी की तुलना में सेवा प्रकार प्रति वर्गीकृत किया परीक्षण Structurize मौजूदा इकाई परीक्षण एक ईश्वर वर्ग