जेनरिक + स्प्रिंग: द फोर्स बी विद यू

एक बार में एक दूर, दूर के बैंक ...

शुभ दिन, हैब्र। आज, आखिरकार, मेरे हाथ फिर से लिखने के लिए यहां पहुंचे। लेकिन पिछले ट्यूटोरियल - लेखों के विपरीत आज मैं अपने अनुभव को साझा करना चाहता हूं और ऐसे तंत्र की शक्ति को जेनरिक के रूप में दिखाना चाहता हूं, जो वसंत जादू के साथ मिलकर और भी मजबूत हो जाता है। मैं आपको तुरंत चेतावनी देना चाहता हूं कि लेख को समझने के लिए आपको स्प्रिंगिंग की मूल बातें जानने की आवश्यकता है और जेनेरिक के बारे में विचार हैं जो "जेनरिक हैं, ठीक है, जो हम ArrayList में उद्धरण चिह्नों में इंगित करते हैं"।

एपिसोड 1:

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

मैंने केवल विरासत के द्वारा सामान्य क्षेत्रों के साथ समस्या को हल किया। इसलिए मुझे कक्षाएं मिलीं:

public class Transfer { private TransferType transferType; ... } public enum TransferType { INTERNAL, SWIFT, ...; } public class InternalTransfer extends Transfer { ... } public class BaseRequest { ... } public class InternalRequest extends BaseRequest { ... } ... 

एपिसोड 2:

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

  @AllArgsConstructor public class TransferController<T extends Transfer> { private final TransferService<T> service; public CheckResponse checkTransfer(@RequestBody @Valid T payment) { return service.checkTransfer(payment); } ... } public class InternalTransferController extends TransferController<InternalTransfer> { public InternalTransferController(TransferService<InternalTransfer> service) { super(service); } } 

खैर, वास्तव में सेवा:

 public interface TransferService<T extends Transfer> { CheckResponse checkTransfer(T payment); ApproveResponse approveTransfer(T payment); ... } 

इस प्रकार, कॉपी-पेस्ट की समस्या केवल सुपरकंस्ट्रक्टर को कॉल करने के लिए कम हो गई थी, और सेवा में हम आम तौर पर इसे खो देते थे।

लेकिन!

एपिसोड 3:

सेवा के अंदर अभी भी एक समस्या थी:
स्थानांतरण के प्रकार के आधार पर, विभिन्न बिल्डरों को बुलाया जाना था:

 RequestBuilder builder; switch (type) { case INTERNAL: { builder = beanFactory.getBean(InternalRequestBuilder.class); break; } case SWIFT: { builder = beanFactory.getBean(SwiftRequestBuilder.class); break; } default: { log.info("Unknown payment type"); throw new UnknownPaymentTypeException(); } } 

सामान्यीकृत बिल्डर इंटरफ़ेस:

 public interface RequestBuilder<T extends BaseRequest, U extends Transfer> { T createRequest(U transfer); } 

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

एपिसोड 4:

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

अनुरोध कक्षाएं:

 public class BaseRequest<T extends Transfer> { ... } public class InternalRequest extends BaseRequest<InternalTransfer> { ... } 

और बिल्डर इंटरफ़ेस:

 public interface RequestBuilder<T extends Transfer> { BaseRequest<T> createRequest(T transfer); } 

और यहाँ यह अधिक दिलचस्प है। हमारा सामना जेनरिक की एक ऐसी विशेषता से है, जिसका उल्लेख लगभग कहीं भी नहीं किया गया है और इसका उपयोग मुख्य रूप से फ्रेमवर्क और लाइब्रेरी में किया जाता है। वास्तव में, बेस्रिस्फेस्ट के रूप में हम इसके वारिस को स्थानापन्न कर सकते हैं, जो कि टाइप टी से मेल खाता है, अर्थात्:

 public class InternalRequestBuilder implements RequestBuilder<InternalTransfer> { @Override public InternalRequest createRequest(InternalTransfer transfer) { return InternalRequest.builder() ... .build(); } } 

फिलहाल, हमने अपने एप्लिकेशन आर्किटेक्चर में एक अच्छा सुधार हासिल किया है। लेकिन स्विच / केस की समस्या अभी तक हल नहीं हुई है। या ...?

एपिसोड 5:

यह वह जगह है जहाँ वसंत जादू खेलने में आता है।

तथ्य यह है कि हमारे पास getBeanNamesForType (ResolvableType प्रकार) विधि का उपयोग करके वांछित प्रकार के अनुरूप बिन नामों की एक सरणी प्राप्त करने का अवसर है। और ResolvableType वर्ग में एक स्थिर विधि forClassWithGenerics (Class <?> Clazz, Class <!> ... generics) है , जहाँ आपको प्रथम पैरामीटर के रूप में class (इंटरफ़ेस) को पास करने की आवश्यकता होती है, जो कि जेनेरिक के रूप में दूसरे पैरामीटर का उपयोग करता है और संबंधित प्रकार लौटाता है। टी ई:

 ResolvableType type = ResolvableType.forClassWithGenerics(RequestBuilder.class, transfer.getClass()); 

निम्नलिखित लौटाता है:

 RequestBuilder<InternalTransfer> 

और अब थोड़ा और जादू - तथ्य यह है कि यदि आप एक जेनेरिक के रूप में इंटरफ़ेस के साथ एक शीट को स्वाहा करते हैं, तो इसके सभी कार्यान्वयन इसमें निहित होंगे:

 private final List<RequestBuilder<T>> builders; 

हमें बस इसके माध्यम से जाना है और उदाहरण चेक का उपयोग करके उपयुक्त ढूंढना है:

 builders.stream() .filter(b -> type.isInstance(b)) .findFirst() .get(); 

इस विकल्प के समान, अभी भी ApplicationContext या BeanFactory को ऑटॉइयर करने का अवसर है, और getBeanNamesForType () विधि उन पर कॉल करें जहां एक पैरामीटर के रूप में हमारे प्रकार को पास करना है। लेकिन यह खराब स्वाद का संकेत माना जाता है और यह वास्तुकला आवश्यक नहीं है (टिप्पणी के लिए zolt85 के लिए विशेष धन्यवाद)।
परिणामस्वरूप, हमारे कारखाने का तरीका निम्नलिखित रूप लेता है:

  @Component @AllArgsConstructor public class RequestBuildersFactory<T extends Transfer> { private final List<RequestBuilder<T>> builders; public BaseRequest<T> transferToRequest(T transfer) { ResolvableType type = ResolvableType.forClassWithGenerics(RequestBuilder.class, transfer.getClass()); RequestBuilder<T> builder = builders.stream() .filter(b -> type.isInstance(b)) .findFirst() .get(); return builder.createRequest(transfer, stage); } } 

एपिसोड 6: निष्कर्ष

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

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

धन्यवाद:
सुल्तानसोई के लिए विशेष धन्यवाद, जिसके बिना इस वास्तुकला को ध्यान में नहीं लाया जाता और, सबसे अधिक संभावना है, यह लेख नहीं था।

संदर्भ:
गितुब स्रोत कोड