प्रतिबिंब के माध्यम से स्वतंत्रता के खिलाफ इंटरफेस के कार्यान्वयन के माध्यम से सीमाएं

हाल ही में, बहुत बार ऐसे फ्रेमवर्क होते हैं जो एक डेवलपर को इंटरफेस से विरासत का सहारा लिए बिना मुक्त रूप में कार्यक्षमता को लागू करने की अनुमति देते हैं। उदाहरण EJB 3, JUnit 4, JSF 2, स्प्रिंग फ्रेमवर्क 3, आदि जैसे देखे जा सकते हैं।
कटौती के तहत आपको दोनों दृष्टिकोणों की चर्चा मिलेगी।

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

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

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

तो, यहाँ कुछ उदाहरण हैं:
1. पहले दृष्टिकोण का उपयोग करके कार्यान्वयन।
कार्यान्वयन के लिए इंटरफेस:

public interface ServiceAsMap {   Map<String, Object> getValue(); } public interface ServiceAsObject {   Object getValue(); } 

और एक उदाहरण कार्यान्वयन:

 public class UserData implements ServiceAsMap {  public Map<String, Object> getValue() {    Map<String, Object> result = new HashMap<String, Object>();    result.put("user.home", "/home/dev");    result.put("user.name", "dev");    return result;  } } public class UserDataObj implements ServiceAsObject {  public Object getValue() {    return context.getUser();  } } 

जैसा कि आप उदाहरण में देख सकते हैं, यह बहुत सुविधाजनक तरीका नहीं है और सहज नहीं है।
अब दूसरे कार्यान्वयन उदाहरण पर विचार करें (मैं आपको याद दिलाता हूं कि आपको किसी इंटरफेस को लागू करने की आवश्यकता नहीं है):

 @Service public class UserData {  public User getUser() {    return context.getUser();  }  public Map<String, String> getProperties() {    Map<String, Object> result = new HashMap<String, Object>();    result.put("user.home", "/home/dev");    result.put("user.name", "dev");    return result;  }  @PropertyName("age")  public int getUserAge() {    return 25;  } } 

जैसा कि आप उदाहरण से देख सकते हैं, विधि के नाम मनमाने तरीके से वर्ग में किए गए कार्यों का वर्णन करते हैं, जो एक ही स्थान पर आपकी ज़रूरत की सभी चीज़ों को लागू करना संभव बनाता है।
उदाहरण में, मैंने उन एनोटेशन का उपयोग किया जो कर्नेल के लिए अतिरिक्त जानकारी ले जाते हैं।
इस दृष्टिकोण का एकमात्र दोष प्रतिबिंब का उपयोग है, जो बहुत तेज़ नहीं है, और इस तरह की संरचना से डेटा को निष्पादित करने और प्राप्त करने के लिए दूसरा कोड बल्कि बोझिल है, इसलिए संभवतः अधिक त्रुटियां हो सकती हैं (यदि आप परीक्षणों को अच्छी तरह से नहीं लिखते हैं)।

प्रिय habrazhiteli, मैं आपके साथ इस दृष्टिकोण पर चर्चा करने में दिलचस्पी रखता हूं दूसरे दृष्टिकोण और अन्य बारीकियों के आवेदन के क्षेत्रों के बारे में जो इस तरह की स्थिति के बारे में सामान्य रूप से हो सकता है।

मैं केवल निर्णय के माध्यम से स्वतंत्रता के उपयोग की वकालत नहीं करता हूं, ऐसे कई उदाहरण हैं जहां एक इंटरफ़ेस से विरासत में एकमात्र सही निर्णय है और प्रतिबिंब केवल हस्तक्षेप करेगा।

आपका ध्यान देने के लिए धन्यवाद।