🍢 👷🏼 👕 उदाहरण के तौर पर @ इम्प्लीमेंट का उपयोग करते हुए संकलन-टाइम एनोटेशन 🧕 ⌛️ 👨🏿‍🎨

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

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

मैं सामान्य सत्यापन एल्गोरिदम, साथ ही साथ सभी चरणों और बारीकियों का वर्णन करूंगा जिनके लिए मैंने समय और तंत्रिका कोशिकाएं बिताई थीं।

समस्या का बयान

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

अब हम कीड़े को ठीक करने की तुलना में कोड की पठनीयता में सुधार के बारे में अधिक बात करेंगे। एक उदाहरण, कोई कह सकता है, जीवन से, या मेरे शौक प्रोजेक्ट से।

मान लीजिए कि एक UnitManager वर्ग है, जो वास्तव में, इकाइयों का एक संग्रह है। इसमें जोड़ने, हटाने, एक इकाई प्राप्त करने आदि की विधियाँ हैं। एक नई इकाई को जोड़ने पर, प्रबंधक इसे एक आईडी प्रदान करता है। आईडी की पीढ़ी को रोटेटकाउंटर वर्ग के लिए सौंप दिया गया है, जो दिए गए रेंज में एक नंबर देता है। और एक छोटी सी समस्या है, रोटेटकाउंटर यह नहीं जान सकता है कि चयनित आईडी मुफ्त है या नहीं। निर्भरता उलटा के सिद्धांत के अनुसार, आप एक इंटरफ़ेस बना सकते हैं, मेरे मामले में यह RotateCounter.IClient है, जिसमें एक एकल विधि हैValueFree (), जो आईडी प्राप्त करता है और आईडी के मुक्त होने पर वापस लौटता है। और UnitManager इस इंटरफ़ेस को लागू करता है, RotateCounter का एक उदाहरण बनाता है और इसे एक ग्राहक के रूप में स्वयं को पास करता है।

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

IClient.isValueFree(int value) { }

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

सबसे पहले, मैंने सोचा था कि जावा में, सी # में, एनोटेशन पूरी तरह से कक्षाएं हैं और उनसे विरासत में प्राप्त किया जा सकता है। इस मामले में, आपको बस एक एनोटेशन बनाने की आवश्यकता है जो @Override से विरासत में मिला है। लेकिन ऐसा नहीं था, और मुझे संकलन के चरण में चेक की अद्भुत और भयावह दुनिया में उतरना पड़ा।

UnitManager नमूना कोड

 public class Unit { private int id; } public class UnitManager implements RotateCounter.IClient { private final Unit[] units; private final RotateCounter idGenerator; public UnitManager(int size) { units = new Unit[size]; idGenerator = new RotateCounter(0, size, this); } public void addUnit(Unit unit) { int id = idGenerator.findFree(); units[id] = unit; } @Implement(RotateCounter.IClient.class) public boolean isValueFree(int value) { return units[value] == null; } public void removeUnit(int id) { units[id] = null; } } public class RotateCounter { private final IClient client; private int next; private int minValue; private int maxValue; public RotateCounter(int minValue, int maxValue, IClient client) { this.client = client; this.minValue = minValue; this.maxValue = maxValue; next = minValue; } public int incrementAndGet() { int current = next; if (next >= maxValue) { next = minValue; return current; } next++; return current; } public int range() { return maxValue - minValue + 1; } public int findFree() { int range = range(); int trysCounter = 0; int id; do { if (++trysCounter > range) { throw new IllegalStateException("No free values."); } id = incrementAndGet(); } while (!client.isValueFree(id)); return id; } public static interface IClient { boolean isValueFree(int value); } }

सिद्धांत की बिट

मैं तुरंत एक आरक्षण करूँगा, उपरोक्त सभी विधियाँ उदाहरण के लिए हैं, इसलिए, संक्षिप्तता के लिए, मैं प्रकार के नाम के साथ और बिना मापदंडों के तरीकों के नामों को इंगित <_>.<_>() : <_>.<_>() ।

संकलन चरण पर तत्वों के प्रसंस्करण में विशेष प्रोसेसर कक्षाएं शामिल हैं। ये ऐसी कक्षाएं हैं जो javax.annotation.processing.AbstractProcessor (आप बस javax.annotation.processing.Processor इंटरफ़ेस को लागू कर सकते हैं) से प्राप्त करते हैं। आप यहां और यहां प्रोसेसर के बारे में अधिक पढ़ सकते हैं। इसमें सबसे महत्वपूर्ण विधि प्रक्रिया है। जिसमें हम सभी एनोटेट तत्वों की एक सूची प्राप्त कर सकते हैं और आवश्यक जांच कर सकते हैं।

 @Override public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment env) { return false; }

सबसे पहले, ईमानदारी से भोला, मैंने सोचा कि संकलन के स्तर पर प्रकारों के साथ काम करना प्रतिबिंब के रूप में किया जाता है, लेकिन ... नहीं। सब कुछ वहां के तत्वों पर आधारित है।

तत्व ( javax.lang.model.element.Element ) - भाषा के अधिकांश संरचनात्मक तत्वों के साथ काम करने के लिए मुख्य इंटरफ़ेस। एक तत्व के वंशज हैं जो किसी विशेष तत्व के गुणों को अधिक सटीक रूप से निर्धारित करते हैं (विवरण के लिए, यहां देखें):

 package ds.magic.example.implement; // PackageElement public class Unit // TypeElement { private int id; // VariableElement public void setId(int id) { // ExecutableElement this.id = id; } }

TypeMirror ( javax.lang.model.type.TypeMirror ) कुछ इस तरह है क्लास <?> GetClass () विधि द्वारा लौटाया जाता है। उदाहरण के लिए, उनकी तुलना यह जानने के लिए की जा सकती है कि तत्वों के प्रकार मेल खाते हैं या नहीं। आप Element.asType() पद्धति का उपयोग करके इसे प्राप्त कर सकते हैं। यह प्रकार कुछ प्रकार के संचालन को भी लौटाता है, जैसे TypeElement.getSuperclass() या TypeElement.getInterfaces() ।

प्रकार ( javax.lang.model.util.Types ) - मैं आपको इस वर्ग पर करीब से नज़र डालने की सलाह देता हूँ। आप वहां बहुत सारी दिलचस्प चीजें पा सकते हैं। संक्षेप में, यह प्रकारों के साथ काम करने के लिए उपयोगिताओं का एक सेट है। उदाहरण के लिए, यह आपको टाइपमेकर से टाइप-क्लेमेंट वापस पाने की अनुमति देता है।

 private TypeElement asTypeElement(TypeMirror typeMirror) { return (TypeElement)processingEnv.getTypeUtils().asElement(typeMirror); }

TypeKind ( javax.lang.model.type.TypeKind ) - एक गणना जो आपको टाइप जानकारी को स्पष्ट करने की अनुमति देती है, जांचें कि क्या प्रकार एक सरणी (ARRAY), एक कस्टम प्रकार (DECLARED), एक प्रकार चर (TYPEVAR), आदि है। आप इसे TypeMirror.getKind() माध्यम से प्राप्त कर सकते हैं

ElementKind ( javax.lang.model.element.ElementKind ) - गणना, आपको तत्व के बारे में जानकारी को स्पष्ट करने की अनुमति देता है, जांचें कि क्या तत्व एक पैकेट (पैकेज), वर्ग (क्लास), विधि (METHOD), इंटरफ़ेस (इंटरफेस), आदि है।

नाम ( javax.lang.model.element.Name ) - तत्व के नाम के साथ काम करने के लिए इंटरफ़ेस, Element.getSimpleName() माध्यम से प्राप्त किया जा सकता है।

मूलतः, ये प्रकार मेरे लिए एक सत्यापन एल्गोरिथ्म लिखने के लिए पर्याप्त थे।

मैं एक और दिलचस्प विशेषता नोट करना चाहता हूं। ग्रहण में तत्व इंटरफेस के कार्यान्वयन org.eclipse ... संकुल में हैं, उदाहरण के लिए, जो तत्व विधियों का प्रतिनिधित्व करते हैं वे प्रकार हैं org.eclipse.jdt.internal.compiler.apt.model.ExecutableElementImpl । इससे मुझे यह विचार आया कि ये इंटरफेस प्रत्येक आईडीई द्वारा स्वतंत्र रूप से लागू किए जाते हैं।

मान्यता एल्गोरिथ्म

पहले आपको एनोटेशन बनाने की आवश्यकता है। इसके बारे में बहुत कुछ लिखा जा चुका है (उदाहरण के लिए, यहाँ ), इसलिए मैं इस पर विस्तार से ध्यान नहीं दूंगा। मैं केवल यह कह सकता हूं कि हमारे उदाहरण के लिए, हमें दो एनोटेशन @Retention और @Retention जोड़ने की आवश्यकता है। पहला इंगित करता है कि हमारा एनोटेशन केवल विधि पर लागू किया जा सकता है, और दूसरा यह कि एनोटेशन केवल स्रोत कोड में ही मौजूद होगा।

एनोटेशन निर्दिष्ट किया जाना चाहिए कि कौन सा इंटरफ़ेस एनोटेट विधि (जिस विधि पर एनोटेशन लागू किया गया है) को लागू करता है। यह दो तरीकों से किया जा सकता है: या तो स्ट्रिंग के साथ इंटरफ़ेस का पूरा नाम निर्दिष्ट करें, उदाहरण के लिए @Implement("com.ds.IInterface") , या इंटरफ़ेस वर्ग को सीधे पास करें: @Implement(IInterface.class) । दूसरा तरीका स्पष्ट रूप से बेहतर है। इस मामले में, कंपाइलर सही इंटरफ़ेस नाम की निगरानी करेगा। वैसे, यदि आप इस सदस्य मूल्य () को कहते हैं, तो विधि में एनोटेशन जोड़ते समय, आपको इस पैरामीटर के नाम को स्पष्ट रूप से निर्दिष्ट करने की आवश्यकता नहीं होगी।

 @Target({ElementType.METHOD}) @Retention(RetentionPolicy.SOURCE) public @interface Implement { Class<?> value(); }

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

 @SupportedAnnotationTypes({"ds.magic.annotations.compileTime.Implement"}) @SupportedSourceVersion(SourceVersion.RELEASE_8) public class ImplementProcessor extends AbstractProcessor { private Types typeUtils; @Override public void init(ProcessingEnvironment procEnv) { super.init(procEnv); typeUtils = this.processingEnv.getTypeUtils(); } @Override public boolean process(Set<? extends TypeElement> annos, RoundEnvironment env) { Set<? extends Element> annotatedElements = env.getElementsAnnotatedWith(Implement.class); for(Element annotated : annotatedElements) { Implement annotation = annotatedElement.getAnnotation(Implement.class); TypeMirror interfaceMirror = getValueMirror(annotation); TypeElement interfaceType = asTypeElement(interfaceMirror); //... } return false; } private TypeElement asTypeElement(TypeMirror typeMirror) { return (TypeElement)typeUtils.asElement(typeMirror); } }

मैं यह नोट करना चाहता हूं कि आप बस वैसे ही मूल्य निर्धारण कर सकते हैं और प्राप्त कर सकते हैं। जब आप annotation.value() को कॉल करने का प्रयास करते हैं, तो एक MirrororedTypeException को फेंक दिया जाएगा, लेकिन इसमें से आप एक TypeMirror प्राप्त कर सकते हैं। यह धोखा विधि, साथ ही मूल्य की सही रसीद, मैंने यहां पाया:

 private TypeMirror getValueMirror(Implement annotation) { try { annotation.value(); } catch(MirroredTypeException e) { return e.getTypeMirror(); } return null; }

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

 private void printError(String message, Element annotatedElement) { Messager messager = processingEnv.getMessager(); messager.printMessage(Kind.ERROR, message, annotatedElement); }

पहला कदम यह जांचना है कि मान एनोटेशन एक इंटरफ़ेस है या नहीं। यहाँ सब कुछ सरल है:

 if (interfaceType.getKind() != ElementKind.INTERFACE) { String name = Implement.class.getSimpleName(); printError("Value of @" + name + " must be an interface", annotated); continue; }

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

 TypeElement enclosingType = (TypeElement)annotatedElement.getEnclosingElement(); if (!typeUtils.isSubtype(enclosingType.asType(), interfaceMirror)) { Name className = enclosingType.getSimpleName(); Name interfaceName = interfaceType.getSimpleName(); printError(className + " must implemet " + interfaceName, annotated); continue; }

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

इस प्रक्रिया में कॉल को लूप के अंत में रखा जाना चाहिए, जैसे:

 if (!haveMethod(interfaceType, (ExecutableElement)annotatedElement)) { Name name = interfaceType.getSimpleName(); printError(name + " don't have \"" + annotated + "\" method", annotated); continue; }

और hasMethod () विधि खुद इस तरह दिखती है:

 private boolean haveMethod(TypeElement interfaceType, ExecutableElement method) { Name methodName = method.getSimpleName(); for (Element interfaceElement : interfaceType.getEnclosedElements()) { if (interfaceElement instanceof ExecutableElement) { ExecutableElement interfaceMethod = (ExecutableElement)interfaceElement; // Is names match? if (!interfaceMethod.getSimpleName().equals(methodName)) { continue; } // Is return types match (ignore type variable)? TypeMirror returnType = method.getReturnType(); TypeMirror interfaceReturnType = method.getReturnType(); if (!isTypeVariable(interfaceReturnType) && !returnType.equals(interfaceReturnType)) { continue; } // Is parameters match? if (!isParametersEquals(method.getParameters(), interfaceMethod.getParameters())) { continue; } return true; } } // Recursive search for (TypeMirror baseMirror : interfaceType.getInterfaces()) { TypeElement base = asTypeElement(baseMirror); if (haveMethod(base, method)) { return true; } } return false; } private boolean isParametersEquals(List<? extends VariableElement> methodParameters, List<? extends VariableElement> interfaceParameters) { if (methodParameters.size() != interfaceParameters.size()) { return false; } for (int i = 0; i < methodParameters.size(); i++) { TypeMirror interfaceParameterMirror = interfaceParameters.get(i).asType(); if (isTypeVariable(interfaceParameterMirror)) { continue; } if (!methodParameters.get(i).asType().equals(interfaceParameterMirror)) { return false; } } return true; } private boolean isTypeVariable(TypeMirror type) { return type.getKind() == TypeKind.TYPEVAR; }

समस्या देखें? नहीं? और वह वहाँ है। तथ्य यह है कि मुझे जेनेरिक इंटरफेस के लिए वास्तविक प्रकार के मापदंडों को प्राप्त करने का कोई तरीका नहीं मिला। उदाहरण के लिए, मेरे पास एक ऐसा वर्ग है जो विधेय इंटरफ़ेस को लागू करता है:

 MyPredicate implements Predicate&ltString&gt { @Implement(Predicate.class) boolean test(String t) { return false; } }

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

ग्रहण से कनेक्ट करें

व्यक्तिगत रूप से, मैं एक्लिप्स से प्यार करता हूं और मेरे अभ्यास में मैंने केवल इसका इस्तेमाल किया। इसलिए, मैं वर्णन करूंगा कि प्रोसेसर को इस आईडीई से कैसे जोड़ा जाए। प्रोसेसर को देखने के लिए ग्रहण के लिए, आपको इसे एक अलग .JAR में पैक करना होगा, जिसमें एनोटेशन भी खुद होगा। इस स्थिति में, आपको प्रोजेक्ट में META-INF / Services फ़ोल्डर बनाने और वहां javax.annotation.processing.Processor फ़ाइल बनाने और प्रोसेसर वर्ग का पूरा नाम इंगित करने की आवश्यकता है: ds.magic.annotations.compileTime.ImplementProcessor , मेरे मामले में। बस के मामले में, मैं एक स्क्रीनशॉट दे दूँगा, लेकिन जब मेरे लिए कुछ भी काम नहीं किया गया, तो मैंने परियोजना की संरचना पर लगभग पाप करना शुरू कर दिया।

अगला, .JAR इकट्ठा करें और इसे अपनी परियोजना से कनेक्ट करें, पहले एक नियमित पुस्तकालय के रूप में, ताकि एनोटेशन कोड में दिखाई दे। फिर हम प्रोसेसर को कनेक्ट करते हैं ( यहां अधिक विस्तृत है)। ऐसा करने के लिए, प्रोजेक्ट गुण खोलें और चुनें:

जावा कंपाइलर -> एनोटेशन प्रोसेसिंग और "एनोटेशन प्रोसेसिंग सक्षम करें" बॉक्स को चेक करें।
जावा कंपाइलर -> एनोटेशन प्रोसेसिंग -> फैक्ट्री पथ "प्रोजेक्ट विशिष्ट सेटिंग्स सक्षम करें" चेकबॉक्स की जाँच करें। फिर Add JARs ... पर क्लिक करें और पहले से निर्मित JAR फ़ाइल चुनें।
परियोजना के पुनर्निर्माण के लिए सहमत हैं।

परिणाम

सभी एक साथ और ग्रहण परियोजना में GitHub पर देखे जा सकते हैं। लेखन के समय, केवल दो वर्ग होते हैं, यदि एनोटेशन कहा जा सकता है: Implement.java और ImplementProcessor.java। मुझे लगता है कि आप पहले से ही उनके उद्देश्य का अनुमान लगा चुके हैं।

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

पुनश्च। बग्स को ठीक करने में मदद के लिए ohotNik_alex और Comdiv के उपयोगकर्ताओं को धन्यवाद।

उदाहरण के तौर पर @ इम्प्लीमेंट का उपयोग करते हुए संकलन-टाइम एनोटेशन

समस्या का बयान

सिद्धांत की बिट

मान्यता एल्गोरिथ्म

ग्रहण से कनेक्ट करें

परिणाम

More articles: