स्थिर और इंस्टॉलेशन विधियों के जोड़े होने के समान कार्य करते हैं?

Question

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

सकारात्मक:

• कुछ लोगों को एक या अन्य का उपयोग करना पसंद है और कुछ मामलों का चयन करने में सक्षम होने में कोड को पढ़ने में आसान बनाता है।

• यह निहित है कि स्थैतिक और इंस्टेंट विधियों दोनों प्रदान किए जाने पर स्थैतिक विधियां उत्परिवर्तित नहीं हो रही हैं। यह बुला कोड अधिक स्पष्ट, उदा .:

  someVector = Vector2d.add(vec1, vec2); 
  someVector = (new Vector2d(vec1)).add(vec2); // does the same thing although more convoluted. 
  
  // similarly adding directly to a vector is simpler with a mutator method. 
  someVector.add(vec2); 
  someVector = Vector2d.add(someVector, vec2); 
  

  यह विशेष रूप से महत्वपूर्ण है जब फ़ंक्शन कॉल की लंबी श्रृंखला उपयोग किया जाता है, जो वैक्टर के साथ आम है बना सकते हैं।

• इन-प्लेस ऑपरेशन प्रत्येक ऑपरेशन के लिए एक नया उदाहरण बनाने से तेज़ी से कम्प्यूटेशनल रूप से हो सकता है। जब उपयोगकर्ता महत्वपूर्ण होता है तो उपयोगकर्ता निर्णय लेता है। एक वेक्टर वर्ग के उपयोगकर्ताओं के लिए, प्रदर्शन महत्वपूर्ण हो सकता है क्योंकि वेक्टर अक्सर कम्प्यूटेशनल रूप से महंगा कोड में उपयोग किए जाते हैं। केवल स्थिर या उदाहरण के तरीकों होने के

पेशेवरों, लेकिन दोनों:

• कोई महत्वपूर्ण कोड अतिरेक। बनाए रखने के लिए आसान है।

• कम ब्लोट। जावाडॉक्स लगभग आधा आकार होगा।

• उपयोगकर्ताओं को सूचित करने के लिए आवश्यक नहीं है कि स्थिर विधियां कभी उत्परिवर्तित नहीं होतीं और गैर-गेटर इंस्टॉलेशन विधियां हमेशा उत्परिवर्तित होती हैं।

स्थैतिक/उदाहरण विधि जोड़े होने पर कितना भयानक है? क्या यह किसी भी प्रमुख पुस्तकालयों में प्रयोग किया जाता है?

क्या पैटर्न "स्थैतिक विधियां उत्परिवर्तित नहीं होते हैं, उदाहरण विधियों को व्यापक रूप से जाना जाता है"?

Answer 1

मुझे लगता है कि दोनों स्थिर/अपरिवर्तनीय और उदाहरण/परिवर्तनशील तरीकों को उपलब्ध कराने की अपनी अवधारणा एक अच्छा एक है। मुझे लगता है कि भेद को समझाना आसान है और एपीआई उपयोगकर्ताओं को समझने और याद रखने के लिए आसान होगा।

मुझे लगता है कि अपने एपीआई कार्यान्वयन कोड निरर्थक व्यापार तर्क नहीं होगा। आप पाएंगे कि आप एक पैटर्न दोहराते हैं जहां स्थिर कार्यान्वयन एक नया उदाहरण बनाता है और उस नए उदाहरण पर इंस्टेंस विधि को कॉल करता है।

यह देखते हुए कि मैं आलसी हूं, मैं कुछ बुनियादी ढांचे का निर्माण करना चाहता हूं जो स्थैतिक तरीकों, उनके जावडोक और उनके यूनिट परीक्षणों को संकलित समय पर स्वतः उत्पन्न करेगा। यदि आपके पास 10 विधियां हैं, तो यह अधिक होगा, लेकिन यदि आपके पास 1,000 तरीके हैं तो बड़ी जीत बन जाती है।

Answer 2

पहले भाग पर, "स्थैतिक विधियां उत्परिवर्तित नहीं होतीं", जिसका व्यापक रूप से ओओपी में उपयोग किया जाता है। मैंने स्पष्ट रूप से व्यक्त किए जाने के बारे में नहीं सुना है। लेकिन यह सामान्य ज्ञान है: "यदि आप कोई ऑब्जेक्ट बदलते हैं, तो यह तरीका स्थिर क्यों होगा यदि यह एक उदाहरण विधि हो?" इसलिए मैं पूरी तरह से "स्थैतिक विधियों को उत्परिवर्तित नहीं करता" से सहमत हूं।

दूसरे भाग पर, "उदाहरण विधियों [mutate]" करते हैं, जो वास्तव में व्यापक रूप से उपयोग नहीं किया जाता है। यह इस बात पर निर्भर करता है कि क्या आप अपरिवर्तनीयता या उत्परिवर्तन लागू करने के लिए अपना डिज़ाइन तय करते हैं या नहीं। जावा एपीआई से उदाहरण: java.lang.String, अपरिवर्तनीय, java.util.Dateपरिवर्तनशील (दुर्घटना/बुरा डिजाइन द्वारा सबसे अधिक संभावना) है java.lang.StringBuilderपरिवर्तनशील जानबूझकर (कि अपने उद्देश्य है) है।अस्थिरता आदेश उत्परिवर्तन कीड़ों से कोड की रक्षा के लिए बचाव की मुद्रा में क्लोनिंग हो सकता है। चाहे यह वास्तव में एक समस्या है कुछ चीजों पर निर्भर करता है:

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

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

समापन, व्यापक रूप से इस्तेमाल धारणा मामले में वस्तु परिवर्तनशील वैसे भी, नहीं तो उदाहरण के तरीकों क्लोन होता है कि "उदाहरण के तरीकों [मे बदलें] करते हैं"।