आइए इसे व्यावहारिक रूप से देखें
Obj 3अब Obj 4मौजूद है। तो क्या? हम क्यों परवाह करते हैं?
डीआईपी का कहना है
"उच्च-स्तरीय मॉड्यूल को निम्न-स्तर के मॉड्यूल पर निर्भर नहीं होना चाहिए। दोनों को अमूर्तता पर निर्भर होना चाहिए।"
ठीक है, लेकिन क्या सभी वस्तुएं अमूर्त नहीं हैं?
डीआईपी भी कहता है
"सार विवरण पर निर्भर नहीं होना चाहिए। विवरण सार पर निर्भर होना चाहिए।"
ठीक है, लेकिन, अगर मेरी वस्तु ठीक से एनकैप्सुलेटेड है, तो क्या यह कोई विवरण नहीं छिपाता है?
कुछ लोग आँख बंद करके इस बात पर जोर देना पसंद करते हैं कि हर वस्तु को एक कीवर्ड इंटरफ़ेस की आवश्यकता है। मैं उनमें से नहीं हूं। मैं आँख बंद करके यह कहना पसंद करता हूं कि यदि आप उनका उपयोग नहीं करने जा रहे हैं, तो आपको बाद में उनके जैसे कुछ की जरूरत से निपटने के लिए एक योजना की आवश्यकता होगी।
यदि आपका कोड हर रिलीज़ पर पूरी तरह से रिफलेक्टर-सक्षम है, तो आप ज़रूरत पड़ने पर बाद में इंटरफेस निकाल सकते हैं। यदि आपने ऐसा कोड प्रकाशित किया है जिसे आप फिर से इकट्ठा नहीं करना चाहते हैं और अपने आप को चाहते हैं कि आप एक इंटरफ़ेस के माध्यम से बात कर रहे हैं तो आपको एक योजना की आवश्यकता होगी।
Obj 3जानता है Obj 4मौजूद है। लेकिन क्या यह Obj 3पता है कि क्या Obj 4ठोस है?
यह यहीं है क्यों यह newहर जगह फैल नहीं करने के लिए बहुत अच्छा है। अगर Obj 3यह नहीं पता है कि Obj 4क्या ठोस है, संभावना है क्योंकि यह इसे नहीं बनाया है, तो अगर आप बाद में झपकी लेते हैं और Obj 4एक अमूर्त वर्ग में बदल जाते Obj 3हैं तो परवाह नहीं करेंगे।
यदि आप ऐसा कर सकते हैं तो Obj 4सभी के साथ पूरी तरह से अमूर्त है। शुरू से ही उनके बीच एक इंटरफेस बनाने वाली एकमात्र चीज आपको यह आश्वासन देती है कि कोई व्यक्ति गलती से कोड जोड़ता है जो Obj 4अभी दूर ठोस है। संरक्षित निर्माणकर्ता उस जोखिम को कम कर सकते हैं लेकिन इससे एक और सवाल बनता है:
क्या Obj 3 और Obj 4 एक ही पैकेज में हैं?
वस्तुओं को अक्सर किसी तरह से समूहित किया जाता है (पैकेज, नाम स्थान आदि)। जब समूह बुद्धिमानी से समूह के बजाय समूह के भीतर अधिक संभावित प्रभावों को बदलते हैं।
मुझे फीचर के आधार पर ग्रुप बनाना पसंद है। तो Obj 3और Obj 4एक ही समूह और परत में हैं यह बहुत संभावना नहीं है कि आप एक प्रकाशित किया है और यह refactor करने के लिए, जबकि केवल एक दूसरे को बदलने की आवश्यकता के नहीं करना चाहता। इसका मतलब यह है कि इन वस्तुओं को एक स्पष्ट आवश्यकता होने से पहले उन दोनों के बीच एक अमूर्त डाल से लाभ होने की संभावना कम है।
यदि आप एक समूह सीमा पार कर रहे हैं, तो यह वास्तव में एक अच्छा विचार है कि दोनों तरफ की वस्तुओं को स्वतंत्र रूप से अलग-अलग किया जाए।
यह सरल होना चाहिए लेकिन दुर्भाग्य से जावा और सी # दोनों ने दुर्भाग्यपूर्ण विकल्प बनाए हैं जो इसे जटिल बनाते हैं।
C # में प्रत्येक कीवर्ड इंटरफ़ेस को एक Iउपसर्ग के साथ नाम देना परंपरा है । वह ग्राहकों को जानने के लिए मजबूर करता है कि वे एक कीवर्ड इंटरफ़ेस से बात कर रहे हैं। वह रिफ्लेक्टरिंग योजना के साथ खिलवाड़ करता है।
जावा में यह एक बेहतर नामकरण पैटर्न का उपयोग करने की परंपरा है: FooImple implements Fooहालांकि, यह केवल स्रोत कोड स्तर पर मदद करता है क्योंकि जावा एक अलग बाइनरी में कीवर्ड इंटरफेस को संकलित करता है। इसका मतलब है कि जब आप Fooकंक्रीट से अमूर्त ग्राहकों के लिए रिफ्लेक्टर करते हैं जिन्हें कोड के एक भी चरित्र की आवश्यकता नहीं होती है जिसे अभी भी बदला हुआ है।
यह इन विशेष भाषाओं में यह BUGS है जो लोगों को औपचारिक अमूर्तता से दूर रखने में सक्षम बनाता है जब तक कि उन्हें वास्तव में इसकी आवश्यकता न हो। आपने यह नहीं कहा कि आप किस भाषा का उपयोग कर रहे हैं, लेकिन समझते हैं कि कुछ ऐसी भाषाएं हैं, जिनमें बस ये समस्याएं नहीं हैं।
आपने यह नहीं कहा कि आप किस भाषा का उपयोग कर रहे हैं, इसलिए मैं आपसे आग्रह करूंगा कि आप अपनी भाषा और स्थिति का सावधानीपूर्वक विश्लेषण करें, इससे पहले कि आप यह तय करें कि यह हर जगह कीवर्ड इंटरफेस होने वाला है।
YAGNI सिद्धांत यहां एक महत्वपूर्ण भूमिका निभाता है। लेकिन ऐसा करता है "कृपया अपने आप को पैर में गोली मारना मुश्किल है"।
