क्रैशप्रूफ कोड: नल सुरक्षित डिजाइन पैटर्न

सामग्री

I. समस्या का विवरण
द्वितीय। मौजूदा समाधानों का अवलोकन
तृतीय। पहलुओं को लागू किए बिना समाधान का भिन्न।
चतुर्थ। AspectJ समाधान
वी। गतिशील पहलू
छठी। उपसंहार।
सातवीं। सन्दर्भ और साहित्य

I. समस्या का विवरण

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

public class SomeBean{ private String strField; public void setStrField(String strField){ this.strField=strField; } public String getStrField(){ return strField; } //    } 

भविष्य में, इस बीन का उपयोग करते समय, हमें शून्य के लिए क्षेत्र की जांच करनी चाहिए:

 String s=someBean.getStrField(); if (s!=null){ if (!s.isEmpty()){ // s.length()>0 Java 5- doSomeThing(); } } 

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

द्वितीय। मौजूदा समाधानों का अवलोकन

मैंने मान लिया कि किसी ने मुझसे पहले ही यह कर लिया है, और मौजूदा समाधानों की समीक्षा की है।

1) JSR-305 से एनोटेशन @ NotNull का विस्तार से वर्णन किया गया है [1] और [2]।
यह खेतों और तरीकों से पहले होता है जो वस्तुओं को वापस करते हैं। आपको पूर्व-निर्धारित आईडीई समस्या क्षेत्रों के स्रोत स्तर पर पहचान करने की अनुमति देता है।

 @NotNull public Color notNullMethod(){ return null; } 

नुकसान: एनोटेशन स्वयं समस्या का समाधान नहीं करता है, और आपको इसे सभी समस्या क्षेत्रों में रखने के लिए याद रखने की आवश्यकता है, JSR-305 जटिल कोड का विश्लेषण करने में सक्षम नहीं है।

2) चेकर फ्रेमवर्क JSR-308 [3] और [4] में वर्णित है।
नल की जाँच करते समय अधिक जटिल कोड का विश्लेषण करने के लिए अतिरिक्त कोड जाँच शुरू करके JSR-305 से अधिक उन्नत तकनीक का प्रतिनिधित्व करता है, और मल्टीटास्किंग, प्रकार, नियमित अभिव्यक्ति और अन्य की जाँच के लिए कई अन्य उपयोगी एनोटेशन भी प्रदान करता है।
लाभ: विकसित रूपरेखा
चर्चा के तहत समस्या के संबंध में नुकसान: @ नोटनल एनोटेशन समाधान प्रदान नहीं करता है, आपको एनोटेशन को सभी समस्या क्षेत्रों में रखना याद रखना चाहिए।

3) जावा एनोटेशन चेकर (JACK) [5] के पास JSR-305 के समान ही फायदे और नुकसान हैं

4) प्रोजेक्ट सिक्का, जिसमें जावा में सुधार (ग्रूवी भाषा से प्रभावित), [6] और [7] में कई सिफारिशें हैं। एक उदाहरण समारोह पर विचार करें:

 public String getPostcode(Person person){ if (person != null){ Address address = person.getAddress(); if (address != null){ return address.getPostcode(); } } return null; } 

प्रोजेक्ट कॉइन के सुझाव पर, इस फ़ंक्शन को NullSafe-नेविगेशन के माध्यम से फिर से लिखा जा सकता है:

 public String getPostcode(Person person){ return person?.getAddress()?.getPostcode(); } 

दुर्भाग्य से, ओरेकल ने इस सुविधा को जावा 7 में शामिल नहीं किया था, इसलिए जावा को अन्य समाधानों के साथ संतोष करना पड़ता है।

5) ग्रूवी भाषा का अनुप्रयोग। दरअसल, ऊपर वर्णित नलसैफ-नेविगेशन वहां से बिल्कुल [8] गया।
प्लस: महत्वपूर्ण कोड सरलीकरण
नुकसान: आपको अभी भी सभी समस्या क्षेत्रों को याद रखने की आवश्यकता है

6) अपाचे कॉमन्स, स्ट्रिंगरिल्ट्स [९] और प्रॉपर्टीयूटिल्स [१०]:

 StringUtils.isBlank(null)= true StringUtils.isBlank("")= true StringUtils.isBlank(" ")= true String firstName = (String) PropertyUtils.getSimpleProperty(employee, "firstName"); String city = (String)PropertyUtils.getNestedProperty(employee, "address(home).city"); 

लाभ: चेक का सरलीकरण
नुकसान: आपको जहां कहीं भी जांच करने की आवश्यकता है। PropertyUtils द्वारा फेंके गए अपवादों को संभालने के लिए अतिरिक्त कोड की आवश्यकता होती है।

7) फाइंडबग्स [11] और पीएमडी [12] स्टैटिक कोड एनालाइजर, जिनमें अधिकांश आईडीई के लिए प्लग-इन हैं।
लाभ: बहुत शक्तिशाली और उपयोगी उपकरण जो एनोटेशन के प्रारंभिक इंजेक्शन के बिना स्थिर कोड का विश्लेषण करते हैं।
नुकसान: समस्या क्षेत्रों को दिखाएं, लेकिन एक तैयार सामान्य समाधान प्रदान न करें।

तृतीय। पहलू के बिना समाधान

अशक्त के लिए जाँच करना, डेटा पढ़ने के किसी भी कार्य की तरह, व्यवहार में अक्सर (लेखन) मूल्यों को निर्दिष्ट करने से अधिक होता है। इसलिए, रीड ऑपरेशन प्रदर्शन के लिए बेहद अनुकूलित होना चाहिए। आप इस मामले में सेम के खेतों के साथ बातचीत को फिर से लिख सकते हैं:

 public class SomeBean{ private String strField=""; public void setStrField(String strField){ if (strField!=null){ this.strField=strField; } } public String getStrField(){ return strField; } } 

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

चतुर्थ। AspectJ समाधान

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

 @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.FIELD, ElementType.TYPE}) public @interface NullSafe { boolean getter() default true; } 

  @NullSafe (गेट्टर = गलत) 

- तर्क को सरल बनाने और प्रदर्शन को बढ़ाने के लिए आवश्यक है यदि प्रोग्रामर बिन में खेतों को शुरू करने के लिए बहुत आलसी नहीं था, तो इस मामले में केवल क्षेत्र में रिकॉर्ड पहलू के संपर्क में है।
भविष्य के आसान संशोधन के लिए, पहलू को एनोटेट एस्पेक्ट 5 का उपयोग करके लिखा गया है और इसके लिए जावा 5+ की आवश्यकता है। पहलुओं के बारे में विवरण [13], [14], [15] में पाया जा सकता है।

 @Aspect public class NullSafeAspect { @Pointcut(value="within(@NullSafe *)") // support annotation by class public void byClass() {} @Pointcut(value="!within(@NullSafe(getter=false) *)") public void byClassNoGetter() {} @Pointcut(value="get(@NullSafe Long||Integer||Double||Float||Short||Byte||java.math.BigDecimal *)") public void fieldGetNumerics() {} @Pointcut(value="!get(@NullSafe(getter=false) * *)") public void fieldNoGetter() {} @Pointcut(value="get(Long||Integer||Double||Float||Short||Byte||java.math.BigDecimal *)") public void classGetNumerics() {} @Pointcut(value="set(Long||Integer||Double||Float||Short||Byte||java.math.BigDecimal *)") public void classSetNumerics() {} @Pointcut(value="set(@NullSafe * *)") // all field-annotated public void fieldSetAllSupported() {} @Pointcut(value="classSetNumerics() || set(String||Boolean||Character *)") public void classSetAllSupported() {} @Pointcut(value="fieldGetNumerics() || get(@NullSafe String||Boolean||Character *)") public void fieldGetAllSupported() {} @Pointcut(value="classGetNumerics() || get(String||Boolean||Character *)") public void classGetAllSupported() {} @Around(value="(fieldSetAllSupported() || byClass() && classSetAllSupported()) && args(v)") public void aroundSet(ProceedingJoinPoint jp, Object v) throws Throwable{ toLogSetter(jp, v); if (v!=null){ jp.proceed();} } @Around(value="get(@NullSafe String *) && fieldNoGetter() || byClass() && get(String *) && byClassNoGetter()") public String aroundGetString(ProceedingJoinPoint jp) throws Throwable{ String v=(String)jp.proceed(); if (v==null){return "";} return v; } private Field getField(JoinPoint jp){ try{ Signature sig=jp.getStaticPart().getSignature(); Field field=sig.getDeclaringType().getDeclaredField(sig.getName()); field.setAccessible(true); return field; }catch(Exception e){ } return null; } private Object getBean(JoinPoint jp){ try { Field field=getField(jp); if (field==null){return null;} Object obj=field.getType().newInstance(); field.set(jp.getTarget(),obj); return obj; }catch(Exception e){ stackTraceToLog(e); } return null; } @Around(value="!fieldGetAllSupported() && get(@NullSafe * *) && fieldNoGetter() && byClassNoGetter()") public Object aroundGetBean(ProceedingJoinPoint jp) throws Throwable{ Object v=jp.proceed(); if (v==null){ return getBean(jp); } return v; } private Object getNumeric(JoinPoint jp){ try { Field field=getField(jp); if (field==null){return null;} Object obj=field.getType().getDeclaredConstructor(String.class).newInstance("0"); field.set(jp.getTarget(),obj); return obj; }catch(Exception e){ stackTraceToLog(e); } return null; } @Around(value="fieldGetNumerics() && fieldNoGetter() || byClass() && classGetNumerics() && byClassNoGetter()") public Object aroundGetNumerics(ProceedingJoinPoint jp) throws Throwable{ Object v=jp.proceed(); if (v==null){ return getNumeric(jp); } return v; } } 

व्याख्या आवेदन उदाहरण:

 @NullSafe public class SomeClassTestByClass extends SomeClass { ... } @NullSafe private String strField; @NullSafe private HashMap<Integer,HashMap<String,String>> map; @NullSafe(getter=false) private ArrayList<String> listString=new ArrayList<String>(); 

निम्नलिखित इस पहलू की व्याख्या है। @Pointcut एनोटेशन मानक प्रतिच्छेदन बिंदुओं का वर्णन करता है। भीतर - का अर्थ है एक वर्ग के अंदर की कार्रवाई, इस मामले में, कोई भी वर्ग @ NullSafe एनोटेशन के साथ चिह्नित है। संख्यात्मक प्रकार Long, Integer, Double, Float, Short, Byte, BigDecimal, जो एक ही पैटर्न द्वारा आरम्भ किए जाते हैं, समर्थित हैं। स्ट्रिंग, बुलियन, चरित्र भी समर्थित हैं। उपरोक्त सभी रैपर कक्षाएं पहलू द्वारा समर्थित प्रकारों की अवधारणा में शामिल हैं। आप क्षेत्र के स्तर पर किसी भी अन्य बिन या वर्ग सहायक निर्माण के बिना एनोटेट भी कर सकते हैं। क्लास एनोटेशन का अर्थ है सभी समर्थित फ़ील्ड प्रकारों के लिए तुरंत पूर्ण समर्थन। इन सभी क्षेत्रों को प्रतिबिंब के साथ आरंभीकृत किया गया है। यदि आप कोड में फ़ील्ड्स इनिशियलाइज़ करते हैं, तो यह @ NullSafe (गेट्टर = गलत) का उपयोग कर गेटर्स को छोड़ कर गति बढ़ाएगा। सेट () और मिलता है () - चौराहे के बिंदुओं पर, वे बिन क्षेत्र को लिखने या पढ़ने के लिए जिम्मेदार हैं, जिसमें बिन के अंदर के क्षेत्रों के साथ संचालन भी शामिल है। @ Advice चौराहे के बिंदुओं पर कार्रवाई के लिए जिम्मेदार है। सेट टू इंट्रस्ट सेट () से पहले टिप का उपयोग करना मेरे लिए एक अच्छा विचार नहीं था, क्योंकि कोड को निष्पादित करने से रोकने के लिए, मुझे एक अपवाद फेंकना पड़ा, जो प्रदर्शन के मामले में अस्वीकार्य था। डिफ़ॉल्ट रूप से, एक पहलू एक सिंगलटन के रूप में बनाया जाता है। परियोजना में प्रत्येक प्रकार के लिए केवल एक विधि के साथ सभी प्रसंस्करण प्रदान किए जाते हैं। परीक्षणों के साथ समाप्त पहलू का एक पूरा उदाहरण NullSafe परियोजना में [18] में दिया गया है।
फायदा: एंड-टू-एंड कार्यक्षमता केवल जहां आवश्यक हो।
नुकसान: आपको अभी भी कक्षाओं और व्यक्तिगत क्षेत्रों के स्तर पर एनोटेशन सेट करने की आवश्यकता है, और @ NullSafe एनोटेशन द्वारा प्रतिबंध के बिना सभी वर्गों के लिए क्रॉस-कटिंग कार्यक्षमता मुझे एक गलत समाधान लगता है।

वी। गतिशील पहलू

पहलू आमतौर पर कोड के लिए स्थिर संशोधन होते हैं और संकलन चरण में किए जाते हैं। इसलिए, चौराहे के बिंदुओं का एक जटिल विवरण समाप्त कार्यक्रम की गति को प्रभावित नहीं करता है। AspectJ बूटलोडर को बदलकर गतिशील रूप से बायटेकोड को संशोधित कर सकता है। यह आवश्यक है जब बाइटकोड के पहलुओं को लागू किया जाए जिसके लिए कोई स्रोत नहीं हैं। इस मामले में, आपको एनोटेशन को हटाने और NullSafeAspect पहलू में कुछ वर्गों के उल्लेख को जोड़ने की आवश्यकता है (या एक नया पहलू बनाएं जो इसे विरासत में मिले)। चूंकि यह तकनीक विभिन्न एप्लिकेशन सर्वर और वातावरण के लिए विशिष्ट है, इसलिए मैं इस पर विस्तार से ध्यान नहीं दूंगा। गतिशील पहलुओं के उपयोग के बारे में अधिक जानकारी [१६] और [१ of] में मिल सकती है।

छठी। अंतभाषण

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

सातवीं। संदर्भ और साहित्य *

1. jcp.org/en/jsr/detail?id=305
2. www.jetbrains.com/idea/documentation/howto.html
3. jcp.org/en/jsr/detail?id=308
4. type.cs.washington.edu/checker-framework/current/checkers-manual.html
5. homepages.ecs.vuw.ac.nz/~djp/JACK
6. blogs.oracle.com/darcy/entry/project_coin_final_five
7. metoojava.wordpress.com/2010/11/15/java-7-awesome-features
8. groovy.codehaus.org/Operators
9. commons.apache.org/lang/api-2.5/org/apache/commons/lang/Stringtt.html
10. commons.apache.org/beanutils/apidocs/org/apache/commons/beanutils/package-summary.html#package_description
11. findbugs.sourceforge.net
12. pmd.sourceforge.net
13. eclipse.org/aspectj/doc/released/adk15notebook/index.html
14. eclipse.org/aspectj/doc/released/progguide/index.html
15. एक्शन में एस्पेक्टज। दूसरा संस्करण। आईएसबीएन 978-1-933988-05-4
16. www.eclipse.org/aspectj/doc/next/devguide/ltw.html
17. static.springsource.org/spring/docs/3.2.x/spring-framework-reference/html/aop.html#aop-aj-ltw
18. sourceforge.net/projects/nullsafe/files
* लेखन के समय सभी इंटरनेट लिंक मान्य थे
02/2013 ओलेग निकोलेन्को