क्या यह संभव है (अनुशंसित) एक शुद्ध एपीआई-प्रोजेक्ट है जो वास्तविक कार्यान्वयन से अलग है?

Question

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

निर्भरता एपीआई-प्रोजेक्ट को संकलन-दायरे के लिए निर्भरता के रूप में सूचीबद्ध करेगी और कार्यान्वयन केवल रनटाइम पर प्रदान किया जाएगा।

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

क्या कोई इसे अभ्यास में डालता है और यह कैसे चला जाता है? सामान्य रूप से आप इसके बारे में क्या सोचते हैं?

Answer 1

यूएमएल आपको इस तरह से मॉडल करने देता है, और कुछ यूएमएल उपकरण मॉडल के आधार पर कोड उत्पन्न करेंगे, जिसमें सिद्धांत समय आने पर यूएमएल से कोड में अंतर को पुल करने में मदद करेगा।

एंटरप्राइज़ आर्किटेक्ट ऐसा एक उपकरण है। लेकिन इसके लिए आपकी टीम को यूएमएल समझदार और कुछ यूएमएल उपकरण के लिए समझदार होने की आवश्यकता है।

Answer 2

मुझे लगता है कि यह एक अच्छा दृष्टिकोण है और इसे हर समय उपयोग करें। मैंने इस तरह से ऐसा करने के लिए कोई वास्तविक नुकसान नहीं अनुभव किया है।

मेरे उपयोग का उदाहरण स्क्रीन-स्क्रैपिंग लाइब्रेरी की तरह कुछ है।

data-source-api 

की तरह एक सेवा है कि:

मैं एक Maven परियोजना के लिए होता है

package my.datasource.api; 

public interface DataSource { 
    public GetDataResponse getData(GetDataRequest request); 
} 

कहाँ GetDataRequest और GetDataResponse (और अन्य एपीआई वर्ग) एपीआई परियोजना में भी कर रहे हैं।

data-source-urlfetch-impl // for appengine 
data-source-http-client-impl // for Apache HTTP client 
data-source-urlconnection-impl // for appengine/vanilla Java 

मेरी कार्यान्वयन से प्रत्येक के लिए:

और यह भी Maven परियोजनाओं कहा जाता है। उदा .:

package my.datasource.urlfetch; 

public class UrlFetchDataSource implements DataSource { 
    ... 
} 

Answer 3

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

Answer 4

मैं इसे एक बहुत देखा है, और फायदे और नुकसान है कि दृष्टिकोण को देखते हैं:

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

तो मुझे लगता है कि यह केवल एपीआई के रूप में एक API प्रकाशित करने के लिए अच्छा है, लेकिन यह वास्तविक स्रोत कोड के बिना एपीआई विकसित करने के लिए, और कभी कभी असली एपीआई के खिलाफ कोड चल रहा है कि कैसे पता चलता बिना लागू करना मुश्किल है यह काम करता हैं।

अलग दृष्टिकोण हो सकता है:

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