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

चलो स्पष्ट के साथ शुरू करते हैं

हम कोड में अपनी समस्या की शर्तों को औपचारिक रूप देते हैं:

public class ImmutableBase { private ImmutableBase(Builder builder) { // ... } public static class Builder { public Builder setSomeString(String value) { // ... return this; } public Builder setSomeInt(int value) { // ... return this; } public ImmutableBase build() { return new ImmutableBase(this); } } } 

अब हमें कुछ वर्ग बनाने की कोशिश करने की जरूरत है जो ImmutableBase से विरासत में मिले हैं। आइए "हेड-ऑन" दृष्टिकोण की कोशिश करें, ImmutableBase कंस्ट्रक्टर के एक्सेस संशोधक को संरक्षित करने के लिए बदलना न भूलें:

 public class MyImmutable extends ImmutableBase { protected MyImmutable(Builder builder) { super(builder); // do more things } public static class Builder extends ImmutableBase.Builder { public Builder setSomeDouble(double value) { // ... return this; } @Override public MyImmutable build() { return new MyImmutable(this); } } public static void main(String[] args) { Builder builder = new Builder(); MyImmutable myImmutable = builder.setSomeDouble(0.0). setSomeInt(0).setSomeString("0").build(); } } 

पहली नज़र में, ऐसा लगता है कि सब कुछ ठीक है। हालांकि, किसी को केवल बिल्डर के तरीकों की कॉल की अदला-बदली करनी है, उदासी हमारे ऊपर कैसे गिरती है:

 MyImmutable.java:20: cannot find symbol symbol : method setSomeDouble(double) location: class ImmutableBase.Builder setSomeInt(0).setSomeDouble(0.0).build(); ^ 

दरअसल, ImmutableBase.Builder में परिभाषित तरीके इसके एक उदाहरण को लौटाते हैं, न कि इसके वंश की एक आवृत्ति।

दूसरा रन

MyImmutable.Builder में अपने पूर्वज से सभी तरीकों को ओवरराइड करने के विचार को तुरंत खारिज करना, हम सोचना शुरू करते हैं। एक लुभावना विकल्प सुरक्षा पर थूकना और कुछ ऐसा करना पसंद करता है

 public <B extends Builder> B setSomeString(String value) { // ... return (B) this; } 

लेकिन, सौभाग्य से (सुरक्षा पर थूकने के लिए कुछ भी नहीं है!), यह समाधान काम नहीं करेगा, सभी समान त्रुटि दे। तथ्य यह है कि इस मामले में, जावा अपने आप में एक प्रकार का अनुमान नहीं लगा सकता है कि इसका उपयोग कैसे किया जाता है, और इसलिए प्रतिबंधों के आधार पर सबसे संकीर्ण संभव प्रकार का चयन करता है। चूंकि हमने लिखा था कि बिल्डर का विस्तार होता है, इसलिए यह प्रकार ImmutableBase.Builder है। अगर हमने यह नहीं लिखा, तो यह ऑब्जेक्ट होगा। आप कंपाइलर को वर्कअराउंड के रूप में बता सकते हैं कि हम किस प्रकार से यह लिखकर उसका इंतजार कर रहे हैं:

 MyImmutable myImmutable = (MyImmutable) builder.setSomeString("0"). <MyImmutable.Builder>setSomeInt(0).setSomeDouble(0.0).build(); 

लेकिन, आपको स्वीकार करना चाहिए, यह पुस्तकालय उपयोगकर्ता के लिए सुविधाजनक नहीं होगा।

आपके सभी सामान्य हमारे हैं!

जेनेरिक के साथ विचार शायद सही था, और इसलिए, यदि आप इस दिशा में थोड़ा और सोचते हैं, तो आप हमारे उदाहरण के लिए निम्नलिखित समाधान प्राप्त कर सकते हैं:

 public static class Builder<B extends Builder<?>> { public B setSomeString(String value) { // ... return (B) this; } public B setSomeInt(int value) { // ... return (B) this; } public ImmutableBase build() { return new ImmutableBase(this); } } 

हालांकि, यहां तक ​​कि टर्मिनल खुशी तक नहीं पहुंची है: हमें कुछ प्रकार नहीं मिला, सुरक्षित, और फिर से त्रुटि प्राप्त करना काफी सरल है:

 public static void main(String[] args) { ImmutableBase.Builder<Builder> builder = new ImmutableBase.Builder<Builder>(); MyImmutable myImmutable = builder.setSomeString("0"). setSomeInt(0).setSomeDouble(0.0).build(); } 

स्टार्टअप पर कारण होगा

 Exception in thread "main" java.lang.ClassCastException: ImmutableBase$Builder cannot be cast to MyImmutable$Builder at MyImmutable.main(MyImmutable.java:24) 

इस तथ्य को देखते हुए कि उपयोगकर्ता ने कुछ भी नहीं डाला है, उन लोगों के बीच भ्रम पैदा कर सकता है जो भूल गए हैं कि संकलक, जब प्रसंस्करण जेनेरिक, आवश्यक जातियों को सम्मिलित करता है। फ़ाइल फिर से है, और यह घातक प्रतीत होगा: समस्या यह है कि MyImmutable.Builder ImmutableBase.Builder का एक उपवर्ग है, और हम इसे हालत से छुटकारा नहीं पा सकते हैं।

साम्राज्य वापस हमला करता है

हालाँकि, हिम्मत मत हारिए! यह थोड़ा अंतर्दृष्टि दिखाने और यह अनुमान लगाने के लिए पर्याप्त है कि उपयोगकर्ता से चिपके रहने वाले वर्ग को उस वर्ग के साथ मेल खाना नहीं है, जिससे हमें MyImmutable से विरासत में मिला है। इसलिए, हम यह करेंगे:

 public class ImmutableBase { protected ImmutableBase(InnerBuilder<?> builder) { // ... } protected static class InnerBuilder<B extends InnerBuilder<B>> { public B setSomeString(String value) { // ... return(B) this; } public B setSomeInt(int value) { // ... return (B)this; } public ImmutableBase build() { return new ImmutableBase(this); } } public static class Builder extends InnerBuilder<Builder> {} } 

इसलिए, हमारे पास इनरबर्ल्ट क्लास है, जो उपयोगकर्ता को दिखाई नहीं देता है, और वह उसके साथ अपना गंदा धोखाधड़ी नहीं कर सकता है; और एक बिल्डर वर्ग है जो केवल उपयोगकर्ता से कार्यान्वयन विवरण (यानी जेनरिक) को छिपाते हुए पहले से विरासत में मिला है। तब यह बिल्डर को MyImmutable में निम्नानुसार घोषित करने के लिए पर्याप्त है:

 public static class Builder extends ImmutableBase.InnerBuilder<Builder> { public Builder setSomeDouble(double value) { // ... return this; } @Override public MyImmutable build() { return new MyImmutable(this); } } 

और जीवन का आनंद लें, क्योंकि कार्य अंततः हल हो गया है। बस के मामले में, मैं आपको दो मुख्य विचारों की याद दिलाता हूँ:

• बिल्डर को एक जेनेरिक क्लास बनाएं, ताकि वापसी के प्रकार की उम्मीद की जाए
• अलग करें कि उपयोगकर्ता को क्या विरासत में मिलेगा और उपयोगकर्ता क्या देखेगा, ताकि वह दुर्भावनापूर्वक इन जेनरिक का उपयोग न कर सके और उन्हें कुछ गलत करने के लिए मजबूर कर सके।

यह समझना आसान है कि इस पद्धति का उपयोग करके गहन वंशानुक्रम करना आसान है, लेकिन यदि आप ऐसा करने की योजना बना रहे हैं, तो आपको सबसे अधिक संभावना है कि आप रिफैक्टरिंग के बारे में सोचें।

आशा है कि यह किसी को समय बचाता है। सौभाग्य!