और फिर से आलस्य के बारे में

शुभ दोपहर

जैसा कि आप जानते हैं, "आलस्य प्रगति का इंजन है", एक प्रोग्रामर का सबसे उपयोगी गुण, इसके लिए बहुत सारे अद्भुत ढांचे दिखाई दिए और इसी तरह आगे भी। लेकिन आज मैं मानवीय आलस्य के बारे में नहीं लिखना चाहता हूं।

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

और अभी से कोडिंग शुरू कर दें

पहला निर्णय "माथे पर है।" हम org.slf4j.Logger इंटरफ़ेस को लागू करते हैं (मैंने slf4j को चुना, लेकिन यह किसी अन्य लॉगिंग फ्रेमवर्क के लिए भी सही है), असली लकड़हारा को घेरता है, इसे शुरू करता है जब कुछ इंटरफ़ेस विधि कहा जाता है। प्रॉक्सी पैटर्न प्लस फैक्टरी विधि। सब कुछ सरल है, सब कुछ काम करता है।

public class LazyLogger implements Logger { private Logger realLogger; private Class<?> clazz; private LazyLogger(Class<?> clazz) { this.clazz = clazz; } public static Logger getLogger(Class<?> clazz) { return new LazyLogger(clazz); } private Logger getRealLogger() { if (realLogger == null) realLogger = LoggerFactory.getLogger(this.clazz); return realLogger; } @Override public void trace(String msg) { getRealLogger().trace(msg); } @Override public void debug(String msg) { getRealLogger().debug(msg); } : :  

लेकिन रुको, org.slf4j.Logger इंटरफ़ेस में लगभग 40 विधियां हैं, क्या मुझे अपने हाथों से उन सभी को लागू करने की आवश्यकता है? और getRealLogger () थ्रेड सेफ नहीं दिखता है। यह अच्छा नहीं है, चलो आगे सोचते हैं।

विषय का विकास करना

वैकल्पिक रूप से, @Delegate एनोटेशन के साथ लोम्बोक है ।

 @AllArgsConstructor(staticName = "getLogger") public class LazyLogger implements Logger { private final static Function<Class<?>, Logger> $function = LoggerFactory::getLogger; private Logger $logger = null; private final Class<?> clazz; @Delegate private Logger getLogger() { if ($logger == null) $logger = $function.apply(clazz); return $logger; } } : private static final Logger logger = LazyLogger.getLogger(MyClass.class); 

@ डेलगेट संकलन के समय org.slf4j.Logger इंटरफ़ेस मेथड बनाने के लिए जिम्मेदार है, अंदर, यह getLogger () + <आवश्यक विधि> कहता है। विधि के लिए पहली कॉल के समय, $ फ़ंक्शन एक वास्तविक लकड़हारा बनाता है। $ उन्हें लोम्बोक से छिपाने के लिए खेतों में जोड़ा गया। यह गेटर्स / सेटर्स उत्पन्न नहीं करता है, ऐसे क्षेत्रों के लिए निर्माता नहीं बनाता है।

तो, यह अच्छा लग रहा है, लेकिन कुछ गायब है। ओह ज़रूर! धागा सुरक्षित है अब GetLogger () में हम एक डबल चेक लिखेंगे, और यहां तक ​​कि AtomicReference के साथ भी! लेकिन रुकिए, लोम्बोक में पहले से ही @Getter (आलसी = सच) है !।

 @RequiredArgsConstructor(staticName = "getLogger") public class LazyLoggerThreadSafe implements Logger { private static final Function<Class<?>, Logger> $function = LoggerFactory::getLogger; private final Class<?> clazz; @Getter(lazy = true, onMethod_ = { @Delegate }, value = AccessLevel.PRIVATE) private final Logger logger = createLogger(); private Logger createLogger() { return $function.apply(clazz); } } : private static final Logger logger = LazyLoggerThreadSafe.getLogger(MyClass.class); 

यहाँ क्या हो रहा है? तथ्य यह है कि एनोटेशन प्रोसेसर जो लोम्बोक एनोटेशन का उपयोग करता है, पिछले चरण में उत्पन्न एनोटेशन को संसाधित करने के लिए स्रोत कोड के माध्यम से कई बार जा सकता है। आप इसके बारे में यहां पढ़ सकते हैं। @Getter (आलसी = सत्य) के पहले पास के दौरान , GetLogger () Lazy initialization के साथ उत्पन्न होता है और इसके @Delegate को एनोटेट करता है। और दूसरे पास के दौरान, @ डेलीगेट से खुद के तरीके उत्पन्न होते हैं ।

और मिठाई के लिए

लेकिन क्या होगा अगर मैं आलसी को एक अन्य ऑब्जेक्ट को इनिशियलाइज़ करना चाहता हूं, न कि लॉगर अगर मुझे एक प्रकार की सार्वभौमिक आलसी फैक्टरी की आवश्यकता है, तो मैं वास्तविक वस्तु बनाने वाले आपूर्तिकर्ता को कहां स्थानांतरित करूंगा? @ डेलीगेट अब हमें नहीं बचाएगा, उसे एक विशिष्ट वर्ग की जरूरत है, जिसमें विशिष्ट तरीकों का एक सेट है। लेकिन इससे कोई फर्क नहीं पड़ता, हम डायनेमिक प्रॉक्सी का उपयोग करते हैं:

 @AllArgsConstructor(access = AccessLevel.PRIVATE) public class LazyFactory<I> { private Class<I> interfaceClass; private Supplier<I> supplier; @SuppressWarnings("unchecked") private I getLazyObject() { return (I) Proxy.newProxyInstance( LazyFactory.class.getClassLoader(), new Class[] { interfaceClass }, new LazyFactory.DynamicInvocationHandler()); } public static <T> T getLazy(Class<T> interfaceClass, Supplier<T> supplier) { return new LazyFactory<T>(interfaceClass, supplier).getLazyObject(); } private class DynamicInvocationHandler implements InvocationHandler { @Getter(lazy = true) private final I internalObject = supplier.get(); @Override public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { return method.invoke(getInternalObject(), args); } } } : public interface Hello { void sayHello(); } public class LazyHello implements Hello { public LazyHello() { System.out.println("LazyHello under constuction"); } @Override public void sayHello() { System.out.println("I'm very lazy for saying Hello.."); } } private static final Hello lazyObj = LazyFactory.getLazy(Hello.class, LazyHello::new); lazyObj.sayHello(); 

जैसा कि आप देख सकते हैं, लोम्बोक के लिए धन्यवाद में, बहुत अधिक कोड नहीं है। यह कैसे काम करता है के कुछ शब्द। एक स्थिर विधि में LazyFactory एक गतिशील प्रॉक्सी देता है। डायनामिकइन्वावेशनहैंडलर के अंदर एक "वास्तविक वस्तु" है, लेकिन इसे केवल तब बनाया जाएगा जब इनवोक () डायनामिकइन्वालेशनहैंडलर कहा जाता है, अर्थात, इंटरफ़ेस I के तरीकों में से एक।
GetInternalObject () जो @Getter (आलसी = सत्य) द्वारा उत्पन्न होता है, "वास्तविक वस्तु" बनाने के लिए जिम्मेदार है।

विषय को और विकसित किया जा सकता है, लेकिन यह पहले से ही स्पष्ट है कि किसी भी चीज का आलसीकरण मौजूदा कोड में एकीकृत करने के लिए सरल, संक्षिप्त और आसान है।

धन्यवाद, ऑल द बेस्ट!

संदर्भ:

JEP ड्राफ्ट: आलसी स्टेटिक फाइनल फील्ड्स
लंबोक