एरे पर काम करने वाले कार्यों के लिए एपीआई डिज़ाइन

Question

मैं संख्यात्मक एल्गोरिदम के सेट के लिए जावा में एक एपीआई डिज़ाइन कर रहा हूं जो युगल के सरणी पर कार्य करता है (वास्तविक समय के वित्तीय आंकड़ों के लिए ऐसा होता है)। प्रदर्शन कारणों से एपीआई को आदिम सरणी के साथ काम करना है, इसलिए List<Double> और ऐसे विकल्प एक विकल्प नहीं हैं।

एक सामान्य उपयोग केस एक एल्गोरिदम ऑब्जेक्ट हो सकता है जो दो इनपुट एरे लेता है, और आउटपुट-सरणी देता है जिसमें दो इनपुट से गणना की गई परिणाम होती है।

मैं, कैसे सरणी पैरामीटर एपीआई में उपयोग किया जाता है के लिए लगातार सम्मेलनों की स्थापना के लिए विशेष रूप से करना चाहते हैं:

• ताकि उपयोगकर्ताओं को एक बड़ा सरणी के कुछ हिस्सों पर कार्य कर सकते हैं मैं सभी कार्यों के साथ एक ऑफसेट शामिल करना चाहिए उदाहरण के लिए someFunction(double[] input, int inputOffset, int length)
• यदि किसी फ़ंक्शन को इनपुट और आउटपुट पैरामीटर दोनों की आवश्यकता होती है, तो इनपुट या आउटपुट पैरामीटर सूची में पहले आना चाहिए?
• क्या कॉलर आउटपुट सरणी आवंटित कर सकता है और उसे पैरामीटर के रूप में पास कर सकता है (जिसे संभावित रूप से फिर से उपयोग किया जा सकता है), या फ़ंक्शन को हर बार आउटपुट सरणी बनाने और वापस करने के लिए क्या करना चाहिए?

उद्देश्यों एक दक्षता, एपीआई उपयोगकर्ताओं और स्थिरता दोनों एपीआई के भीतर और स्थापित परंपराओं से के लिए सादगी की एक संतुलन हासिल करने हैं।

स्पष्ट रूप से बहुत सारे विकल्प हैं, तो सबसे अच्छा समग्र एपीआई डिज़ाइन क्या है?

Answer 1

ताकि वास्तव में तीन प्रश्न की तरह लगता है, इसलिए यहाँ मेरी राय हैं।

बेशक

, यह बहुत व्यक्तिपरक है - तो - अपने लाभ भिन्न हो सकते हैं:

1. हां। हमेशा ऑफसेट & लंबाई शामिल करें। यदि किसी विशेष फ़ंक्शन के लिए अधिकांश मामलों का उपयोग नहीं है तो उन पैरामीटरों की आवश्यकता है, फ़ंक्शन को अधिभारित करें ताकि इनपुट & लंबाई आवश्यक न हो।

2. इस के लिए, मैं मानक arraycopy द्वारा प्रयोग किया जाता का पालन करेगा:

   arraycopy (वस्तु src, srcPos int, वस्तु गंतव्य इंट destPos, पूर्णांक लंबाई)

3. प्रदर्शन अंतर यहाँ जा रहा है नगण्य जब तक कॉलर बार-बार आपके उपयोगिता कार्यों को बुलाता है। अगर वे चीजों से सिर्फ एक हैं, तो कोई फर्क नहीं पड़ता। यदि उन्हें बार-बार कहा जाता है तो आपको कॉलर को आवंटित सरणी भेजनी चाहिए।

Answer 2

1. यदि आप करते हैं, तो एक डिफ़ॉल्ट विकल्प भी प्रदान करें (0 से शुरू होता है, पूर्ण लंबाई)।
2. मुझे लगता है कि अधिकतर उपयोगकर्ता आउटपुट 2 की अपेक्षा करेंगे। हालांकि, अगर आप varargs का उपयोग कर सकते हैं, जो आपके दिमाग को बदल सकता है।
3. मुझे आउटपुट सरणी में गुजरने वाले कॉलर पसंद है, लेकिन शून्य के लिए एक विकल्प के साथ, जिसका मतलब है कि विधि आवंटित की जाएगी।

vararg टिप्पणी पर विस्तार से, मान लें कि आपके पास दो सरणी जोड़ने का तरीका है। यदि आप आउटपुट सरणी तर्क को पहले तर्क के रूप में रखते हैं, और अंत में 2 इनपुट सरणी डालते हैं, तो एन एरे जोड़ने के लिए विधि को विस्तारित करना छोटा होता है।

# 3 पर विस्तार से, कॉलर्स आउटपुट सरणी में पास होने देते हैं, कभी-कभी यह अधिक कुशल होता है। और, यदि लाभ नगण्य है, तो आपके उपयोगकर्ता, आदिम सरणी से निपटने वाले, शायद सी या फोरट्रान पृष्ठभूमि से आए हैं, और लगता है कि लाभ बड़ा होगा और अगर आप उन्हें "कुशल" होने की अनुमति नहीं देते हैं तो शिकायत करेंगे। :-)

Answer 3

मान लीजिए कि आप स्टैक पर या ईडन में आवंटित करने के लिए पर्याप्त छोटे सरणी के साथ काम कर रहे हैं, आवंटन बेहद तेज़ है। इसलिए, परिणामों को वापस करने के लिए अपने स्वयं के सरणी आवंटित करने में कोई हानि नहीं है। ऐसा करने के लिए पठनीयता के लिए एक बड़ी जीत है।

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

Answer 4

मैं List<Double> का उपयोग करें और तरीकों के लिए एक नया List के रूप में उत्पादन लौट होगा:

public List<Double> someFunction(List<Double> input) 

Answer 5

कई कार्यों को उजागर करने वाले एपीआई डिज़ाइन के बारे में मुख्य बात इसकी आंतरिक स्थिरता है। बाकी सब कुछ एक दूसरे के रूप में आता है।

इंडेक्स/लम्बाई जोड़े पास करने या नहीं, इस पर निर्भर करता है कि एपीआई का उपयोग करने की अपेक्षा की जा रही है। यदि आप उपयोगकर्ताओं को विधि कॉल की श्रृंखला लिखने की उम्मीद करते हैं जो System.arrayCopy में उसी सरणी के विभिन्न सेगमेंट में डेटा लेते या डालते हैं, तो आपको इंडेक्स/लम्बाई जोड़े की आवश्यकता होती है। अन्यथा, यह एक overkill है।

इनपुट पहले या आउटपुट पहले आपका निर्णय है, लेकिन एक बार जब आप इसे बनाते हैं, तो समान हस्ताक्षर वाले सभी तरीकों से इसके साथ चिपके रहें।

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

Answer 6

मुझे लगता है कि एपीआई डिजाइन काफी हद तक व्यक्तिपरक है, और/या एपीआई "उपयोग-मामलों" से भारी प्रभावित होना चाहिए। दूसरी तरफ, आपके एपीआई के लिए उपयोग के मामले क्लाइंट कोड पर पूरी तरह से हैं। सभी मापदंडों के साथ

एक विधि:

कि सभी ने कहा है, व्यक्तिगत रूप से, मैं विधि से अधिक भार का लाभ ले जाएगा और निम्नलिखित संरचना के लिए जाना

void someFunction(int[] input1, int[] input2, int offset, int length, int[] output)

यह मुख्य कार्य है। अन्य सभी फ़ंक्शंस इसे उचित पैरामीटर के साथ कॉल करें।

int[] someFunction(int[] input1, int[] input2, int offset, int length)

यह पहला समारोह कहता है, लेकिन आबंटित तथा फोन करने वाले की ओर से उत्पादन सरणी देता है।

void someFunction(int[] input1, int[] input2, int[] output)

int[] someFunction(int[] input1, int[] input2)

नोट पैरामीटर सूची को नष्ट करने 'वैकल्पिक' मापदंडों से कम करने के लिए है कि सामान्य रणनीति।

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