एक इंटरफ़ेस के बजाय खाली सार श्रेणी का उपयोग क्यों करें?

Question

मैं जीडब्ल्यूटी और प्लेस & गतिविधि तंत्र का उपयोग करता हूं।

यह वास्तव में दुखी है कि स्थान एक वर्ग है क्योंकि मेरा कस्टम स्थान किसी अन्य वर्ग का विस्तार नहीं कर सकता है।

public abstract class Place { 

    /** 
    * The null place. 
    */ 
    public static final Place NOWHERE = new Place() { 
    }; 

} 

कि देखकर, जहाँ एक इंटरफेस हो सकता है:

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

और सामान्यीकृत करने के लिए: वास्तव में खाली अमूर्त वर्ग बनाम इंटरफ़ेस बनाने का कोई अच्छा कारण है?

Answer 1

मैं वास्तव में Place के लिए नहीं बता सकता है (हालांकि मैं कुछ विचार है, नीचे देखें), लेकिन यह Activity के लिए चर्चा की गई: https://groups.google.com/d/topic/google-web-toolkit-contributors/V8rhZHiXFRk/discussion

जहां तक ​​हमारा इतिहास में जा सकते हैं, Placealways been है जीडब्ल्यूटी में एक अमूर्त वर्ग (और एफडब्ल्यूआईडब्ल्यू, NOWHERE स्थान long after जोड़ा गया था; ध्यान दें कि यह प्रतिबद्धता इंटरनेट से गायब होने के लिए वेव-सून का संदर्भ देती है- जहां हम interface Place देख सकते हैं, इसलिए यह कुछ समय पर एक इंटरफेस था जब उन्होंने डिजाइन किया था एपीआई)।

यह देखते हुए कि PlaceHistoryGenerator (GWT.create() पर उपयोग किया जाता है) स्थान पदानुक्रम को देखते हुए, एक सार वर्ग पूरे किनारे के मामलों में कटौती करता है!
कल्पना करें कि PlaceHistoryMapper संदर्भ PlaceTokenizers<Foo> और PlaceTokenizer<Bar> और आपके पास class FooBar implements Foo, Bar { } है, जो टोकननाइज़र का उपयोग किया जाना चाहिए? यदि आप कक्षा को अपने PlaceHistoryMapper में स्पष्ट रूप से संदर्भित नहीं करते हैं, तो जनरेटर इसे नहीं देख पाएगा (या इसके बजाय इसे नहीं देखेगा), तो किस प्रकार का कोड उत्पन्न होना चाहिए? और ध्यान रखें कि हम सभी दृढ़तावाद चाहते हैं, इसलिए जेनरेट कोड हमेशा एक जैसा होना चाहिए। एक वर्ग का उपयोग करके, जेनरेटर उन्हें अपने विरासत के पेड़ (सबसे विशिष्ट - सबसे व्युत्पन्न से कम से कम विशिष्ट तक) द्वारा आदेश दे सकता है, और सुरक्षित रूप से यह मान सकता है कि जिन स्थानों के वर्गों में कोई विशेष विरासत संबंध नहीं है, वे पूरी तरह से अलग हैं, इसलिए वे हो सकते हैं जेनरेट कोड में चेक किया गया (instanceof) किसी भी क्रम में और अभी भी स्थिर परिणाम ⇒ निर्धारणा प्रदान करता है।

अस्वीकरण: मैं एक है जो आदेश मुद्दे और फिर provided the patchreported हूँ, लेकिन Place पहले से ही एक वर्ग था।

Answer 2

सामान्य तौर पर मैं एक खाली सार वर्ग

हालांकि, जब मैं भविष्य में कुछ सदस्यों उम्मीद होती है, मैं इंटरफ़ेस के बजाय सार वर्ग का उपयोग करने का फैसला कर सकते परिभाषित नहीं होता

"वर्ग" का अर्थ है: यह एक

"इंटरफेस" का अर्थ है: इसका समर्थन

"प्लेस" मैं वास्तव में वर्ग के लिए एक छोटे से सहज ज्ञान युक्त वरीयता के साथ दोनों देख सकते हैं के लिए

Answer 3

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

मैं एक के बारे में नहीं सोच सकता। लेकिन यथार्थवादी होने के लिए, एसओ पर इसके बारे में शिकायत करना कुछ हासिल करने वाला नहीं है।

और सामान्यीकृत करने के लिए: वास्तव में खाली अमूर्त वर्ग बनाम इंटरफ़ेस बनाने का कोई अच्छा कारण है?

हाइपोटेटिक रूप से, आप यह सुनिश्चित करने के लिए ऐसा कर सकते हैं कि भविष्य की अनुमानित आवश्यकताओं के लिए एक सामान्य आधार वर्ग है ... या किसी अन्य कारण से।

लेकिन आम तौर पर यह एक बुरा विचार है ... आईएमओ।

(बेशक, इस तरह की बातें अक्सर ऐतिहासिक कारणों से हो;। जैसे abstract वर्ग अतीत में अधिक सदस्यों को बताया कि जब से हटा दिया गया है हो सकता था)

Answer 4

मैं GWT टीम के लिए नहीं बोल सकता, लेकिन इस अमूर्त वर्ग के लिए ऐसा लगता है कि नौवहन की परिभाषा को मजबूर करना एकमात्र कारण है।

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

यह उदाहरण विशेष रूप से अजीब है क्योंकि इंटरफेस एक अनुबंध है। जीडब्ल्यूटी Place में कोई इंटरफ़ेस नहीं है और इसलिए कोई अनुबंध नहीं है।उनके जावाडोक कहता है:

मैं कुछ अनुबंध इस परिदृश्य से निपटने के लिए परिभाषित की उम्मीद है | "किसी एप्लिकेशन में एक बुकमार्क योग्य स्थान का प्रतिनिधित्व करता है"। एक बुकमार्क करने योग्य स्थान की क्या आवश्यकता होगी? यदि यह सिर्फ एक मार्कर है, जैसे Serializable, तो मैं निश्चित रूप से यह एक अमूर्त वर्ग की बजाय एक इंटरफ़ेस होने की अपेक्षा करता हूं।