2011-05-22 12 views
6

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

import java.util.List; 

public abstract class Separation { 

    public static final Separation INSTANCE = new SeparationImpl(); 

    // Defining a special list 
    public static interface MySpecialList<T> extends List<T> { 
     void specialAdd(T item); 
    } 

    // Creation of a special list 
    public abstract <T> MySpecialList<T> newSpecialList(Class<T> c); 

    // Merging of a special list 
    public abstract <T> MySpecialList<? extends T> specialMerge(
     MySpecialList<? super T> a, MySpecialList<? super T> b); 

    // Implementation of separation 
    public static class SeparationImpl extends Separation { 

     @Override 
     public <T> MySpecialList<T> newSpecialList(Class<T> c) { 
      return ...; 
     } 

     @Override 
     public <T> MySpecialList<? extends T> specialMerge(
      MySpecialList<? super T> a, MySpecialList<? super T> b) { 
      return ...; 
     } 

    } 

} 

कुछ है कि API कार्यान्वयन कोड का उल्लेख नहीं करना चाहिए का तर्क होगा:

निम्न उदाहरण एक API डिजाइन और उदाहरण वस्तु के माध्यम से इसके कार्यान्वयन की एक मंगलाचरण को दर्शाता है। भले ही हम एपीआई कोड को अलग-अलग फाइलों के माध्यम से कार्यान्वयन से अलग करते हैं, फिर भी अक्सर एपीआई में कार्यान्वयन कोड (कम से कम कक्षा का नाम) आयात करना होता है।

पूरी तरह से योग्य नाम के स्ट्रिंग प्रस्तुति का उपयोग करके ऐसे संदर्भों से बचने के लिए तकनीकें हैं। वर्ग उस स्ट्रिंग के साथ भरा हुआ है और फिर तत्काल। यह कोड को और अधिक जटिल बनाता है।

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

उत्तर

6

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

उदाहरण के तौर पर, विभिन्न संग्रह वर्गों में पुनरावृत्ति को कैसे कार्यान्वित किया जाता है देखें। विशिष्ट संग्रहों में तत्वों को पुनर्प्राप्त करने के अधिक विशिष्ट तरीके हैं (उदाहरण के लिए एक ऐरेलिस्ट में स्थिति द्वारा) लेकिन वे Collection में प्रकट नहीं हुए हैं क्योंकि वे ठोस ArrayList को कार्यान्वित करने के तरीके के लिए विशिष्ट हैं।

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

3

ओएसजीआई में अक्सर उपयोग की जाने वाली एक तकनीक एपीआई को कार्यान्वयन के लिए एक अलग मॉड्यूल में रखना है। एपीआई को सीधे कार्यान्वयन के किसी भी संदर्भ से परहेज करना चाहिए।

+0

क्या यह ओएसजीआई या सिर्फ अच्छे प्रथाओं के लिए एक पूर्ण आवश्यकता है? – JVerstry

+0

आईपीओजेओ जैसे कुछ ढांचे का उपयोग करने के लिए, लेकिन आपको सभी मामलों में ऐसा करने की ज़रूरत नहीं है (और मैं नहीं) –

2

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

: नमूना वर्ग पदानुक्रम सिर्फ मानक संग्रह पुस्तकालय

interface List --> AbstractList --> ArrayList 
+0

भले ही केवल एक उत्पादन कार्यान्वयन हो, एबीसी और इंटरफेस अभी भी एक अच्छी बात है; सबसे पहले, वे चिंताओं के साफ अलगाव को लागू करते हैं। दूसरा, वे मोक्स के माध्यम से आसान इकाई परीक्षण की अनुमति देते हैं। –

+0

मैं तथ्य यह है कि कभी कभी, आप एक तरह से एपीआई से ही प्रदान करना है एक API का इन्स्टेन्शियशन का उपयोग की जरूरत है और वर्णन करने के लिए कोशिश कर रहा था। मैं सहमत हूं, यह केवल एक इंटरफ़ेस के साथ किया जा सकता था। – JVerstry

+0

@Oli चार्ल्सवर्थ - हम ठोस वर्ग में कम से कम उद्देश्य मजाक के लिए इंटरफेस है करने की कोई जरूरत नकली कर सकते हैं। – Premraj

1

अच्छा अंक के अतिरिक्त अन्य लेखकों से मैं इकाई परीक्षण प्रयोजनों के उल्लेख की तरह की तरह

interface Separation --> AbstractSeparation --> SeparationImpl 

लगेगा कक्षाओं के अंतरफलक होने पर ऑब्जेक्ट्स का नकल करना बहुत आसान होता है।