इस संदर्भ में "बाहरी" का अर्थ है "उपयोगकर्ताओं के लिए अवलोकन योग्य"। किसी एप्लिकेशन या किसी सार्वजनिक API के मामले में अन्य कार्यक्रमों के मामले में उपयोगकर्ता मनुष्य हो सकते हैं।
इसलिए यदि आप क्लास M से क्लास B तक की विधि M को स्थानांतरित करते हैं, और दोनों कक्षाएं किसी एप्लिकेशन के अंदर गहरी हैं, और कोई भी उपयोगकर्ता परिवर्तन के कारण ऐप के व्यवहार में किसी भी परिवर्तन का पालन नहीं कर सकता है, तो आप इसे सही तरीके से रीफैक्टरिंग कह सकते हैं।
यदि, OTOH, कुछ अन्य उच्च स्तरीय सबसिस्टम / घटक अपने व्यवहार को बदल देता है या परिवर्तन के कारण टूट जाता है, तो यह वास्तव में (आमतौर पर) उपयोगकर्ताओं के लिए अवलोकन योग्य है (या कम से कम sysadmins लॉग की जाँच करने के लिए)। या अगर आपकी कक्षाएं एक सार्वजनिक एपीआई का हिस्सा थीं, तो वहां 3 पार्टी कोड हो सकता है जो एम वर्ग ए का हिस्सा होने पर निर्भर करता है, बी नहीं। इसलिए इनमें से कोई भी मामले सख्त अर्थों में नहीं हैं।
किसी भी कोड के काम को कॉल करने की प्रवृत्ति है, जो कि मुझे लगता है कि गलत है।
वास्तव में, यह एक दु: खद लेकिन अपेक्षित परिणाम है, जो फैशनेबल बनने की ओर अग्रसर होता है। डेवलपर्स उम्र के लिए एक तदर्थ तरीके से कोड rework कर रहे हैं, और यह निश्चित रूप से आसान है कि एक नई गूढ़ता को जानने के लिए और विश्लेषण करने की आदतें बदलें।
तो बाहरी व्यवहार को बदलने वाले reworks के लिए सही शब्द क्या है?
मैं इसे नया स्वरूप कहूंगा ।
अद्यतन करें
इंटरफ़ेस के बारे में बहुत सारे दिलचस्प जवाब, लेकिन इस पद्धति को स्थानांतरित करने से इंटरफ़ेस में बदलाव नहीं होगा?
किस? विशिष्ट वर्ग, हाँ। लेकिन क्या ये वर्ग किसी भी तरह से प्रत्यक्ष रूप से बाहरी दुनिया को दिखाई देते हैं? यदि नहीं - क्योंकि वे अपने कार्यक्रम के अंदर हैं, और नहीं के बाहरी इंटरफ़ेस (API / जीयूआई) के हिस्से के कार्यक्रम (जब तक परिवर्तन टूट जाता है कुछ, निश्चित रूप से) कोई परिवर्तन नहीं किया वहाँ बाहरी पार्टियों द्वारा मानने योग्य है -।
मुझे लगता है कि इससे परे एक गहरा सवाल है: क्या एक विशिष्ट वर्ग अपने आप में एक स्वतंत्र इकाई के रूप में मौजूद है? ज्यादातर मामलों में, उत्तर नहीं है : वर्ग केवल एक बड़े घटक के रूप में मौजूद है, कक्षाओं और वस्तुओं का एक पारिस्थितिकी तंत्र, जिसके बिना इसे तत्काल नहीं किया जा सकता है और / या अनुपयोगी है। इस पारिस्थितिकी तंत्र में न केवल इसकी (प्रत्यक्ष / अप्रत्यक्ष) निर्भरता शामिल है, बल्कि अन्य वर्ग / वस्तुएं भी हैं जो इस पर निर्भर हैं। ऐसा इसलिए है क्योंकि इन उच्च स्तरीय कक्षाओं के बिना, हमारी कक्षा से जुड़ी जिम्मेदारी सिस्टम के उपयोगकर्ताओं के लिए अर्थहीन / बेकार हो सकती है।
जैसे हमारे प्रोजेक्ट में जो कार किराए पर देने का काम करता है, एक है Chargeकक्षा। इस वर्ग का सिस्टम के उपयोगकर्ताओं के लिए अपने आप में कोई उपयोग नहीं है, क्योंकि किराये के स्टेशन एजेंट और ग्राहक एक व्यक्तिगत शुल्क के साथ बहुत कुछ नहीं कर सकते हैं: वे एक पूरे के रूप में किराये के अनुबंध के अनुबंध से निपटते हैं (जिसमें विभिन्न प्रकार के शुल्क शामिल हैं) । उपयोगकर्ता इन शुल्कों के कुल योग में रुचि रखते हैं, वे अंत में भुगतान करने वाले हैं; एजेंट विभिन्न अनुबंध विकल्पों, किराये की लंबाई, वाहन समूह, बीमा पैकेज, अतिरिक्त आइटम आदि आदि में रुचि रखता है, जो चयनित हैं, (परिष्कृत व्यापार नियमों के माध्यम से) यह दर्शाता है कि क्या शुल्क मौजूद हैं और अंतिम भुगतान की गणना कैसे की जाती है। इनमें से। और देश के प्रतिनिधि / व्यापार विश्लेषक विशिष्ट व्यावसायिक नियमों, उनके तालमेल और प्रभावों (कंपनी की आय पर, आदि) के बारे में परवाह करते हैं।
हाल ही में मैंने इस वर्ग को बदल दिया, इसके अधिकांश क्षेत्रों और विधियों का नाम बदलकर (मानक जावा नामकरण सम्मेलन का पालन करने के लिए, जो हमारे पूर्ववर्तियों द्वारा पूरी तरह से उपेक्षित था)। मैं Stringऔर charअधिक उपयुक्त enumऔर booleanप्रकारों के साथ फ़ील्ड्स को बदलने के लिए और भी रिफ्लेक्टर की योजना बनाता हूं । यह सब निश्चित रूप से कक्षा के इंटरफ़ेस को बदल देगा, लेकिन (अगर मैं अपना काम सही ढंग से करता हूं) तो इसमें से कोई भी हमारे ऐप के उपयोगकर्ताओं को दिखाई नहीं देगा। उनमें से किसी को भी परवाह नहीं है कि व्यक्तिगत आरोपों का प्रतिनिधित्व कैसे किया जाता है, भले ही वे निश्चित रूप से चार्ज की अवधारणा को जानते हों। मैं किसी भी डोमेन अवधारणा का प्रतिनिधित्व नहीं करने वाले सौ अन्य वर्गों के उदाहरण के रूप में चुना जा सकता था, इसलिए अंत उपयोगकर्ताओं के लिए भी वैचारिक रूप से अदृश्य रहा, लेकिन मैंने सोचा कि एक उदाहरण चुनना अधिक दिलचस्प है जहां अवधारणा स्तर पर कम से कम कुछ दृश्यता है। यह अच्छी तरह से दर्शाता है कि वर्ग इंटरफेस केवल डोमेन अवधारणाओं का प्रतिनिधित्व करते हैं (सबसे अच्छे रूप में), वास्तविक चीज़ * नहीं। अवधारणा को प्रभावित किए बिना प्रतिनिधित्व को बदला जा सकता है। और उपयोगकर्ता केवल अवधारणा को समझते हैं और समझते हैं; अवधारणा और प्रतिनिधित्व के बीच मानचित्रण करना हमारा काम है।
* और कोई भी आसानी से उस डोमेन मॉडल को जोड़ सकता है, जो हमारी कक्षा का प्रतिनिधित्व करता है, वह स्वयं केवल कुछ "वास्तविक चीज़" का एक अनुमानित प्रतिनिधित्व है ...