सार कक्षा के साथ-साथ इंटरफ़ेस की आवश्यकता है?

Question

एक इंटरफेस एक 100% सार वर्ग है, इसलिए हम कुशल प्रोग्रामिंग के लिए एक इंटरफेस का उपयोग कर सकते हैं। क्या कोई ऐसी स्थिति है जहां एक अमूर्त वर्ग इंटरफ़ेस से बेहतर है?

Answer 1

सार कक्षाएं उपयोग किया जाता है जब आप एक ठोस वर्ग, बनाने का इरादा रखते हैं, लेकिन यह सुनिश्चित करना चाहते हैं सभी उपवर्गों में कुछ आम राज्य या कुछ कार्यों के लिए एक संभावित सामान्य कार्यान्वयन नहीं है।

इंटरफेस में या तो शामिल नहीं हो सकता है।

Answer 2

सार कक्षा v/s इंटरफ़ेस एक विषय है जो जावा के लिए नए किसी भी व्यक्ति के लिए जिज्ञासा/रुचि/भ्रम पैदा करता है और गहराई से खोदना चाहता है।

This article विषय पर विस्तृत स्पष्टीकरण प्रदान करता है।

Answer 3

हां, अमूर्त वर्गों और इंटरफेस दोनों के लिए एक जगह है।

चलिए एक ठोस उदाहरण के साथ चलते हैं। हम एक और SavingsAccount को एक सार AbstractBankAccount से कैसे देखेंगे और देखें कि हम दो प्रकार के खातों को अंतरफलक का उपयोग कैसे कर सकते हैं।

शुरू करने के लिए, यहाँ एक अमूर्त वर्ग AbstractBankAccount है:

abstract class AbstractBankAccount 
{ 
    int balance; 
    public abstract void deposit(int amount); 
    public abstract void withdraw(int amount); 
} 

हम balance और दो तरीकों deposit और withdraw कि उपवर्गों से लागू किया जाना चाहिए के रूप में खाते की शेष राशि की है।

जैसा कि हम देख सकते हैं, अमूर्त वर्ग संरचना को की घोषणा करता है कि बैंक खातों को कैसे परिभाषित किया जाना चाहिए। जैसा कि @Uri ने अपनी प्रतिक्रिया में उल्लेख किया है, इस अमूर्त वर्ग में राज्य है, जो balance फ़ील्ड है। यह एक इंटरफ़ेस के साथ संभव नहीं होगा।

अब, चलो उपवर्ग AbstractBankAccount एक CheckingAccount

class CheckingAccount extends AbstractBankAccount 
{ 
    public void deposit(int amount) 
    { 
     balance += amount; 
    } 

    public void withdraw(int amount) 
    { 
     balance -= amount; 
    } 
} 

इस उपवर्ग CheckingAccount में बनाने के लिए, हम दो सार कक्षाएं लागू किया - यहाँ कुछ नहीं भी दिलचस्प।

अब, हम SavingsAccount को कैसे कार्यान्वित कर सकते हैं? यह CheckingAccount से अलग है जिसमें इससे ब्याज प्राप्त होगा। deposit विधि का उपयोग कर ब्याज बढ़ाया जा सकता है, लेकिन फिर, ऐसा नहीं है कि ग्राहक अपनी रुचि जमा कर रहा है। इसलिए, यह अधिक स्पष्ट हो सकता है अगर हमारे पास खाते में पैसा जोड़ने का एक और माध्यम है, खासकर ब्याज के लिए, accrueInterest विधि।

हम सीधे SavingsAccount में विधि को लागू कर सकता है, लेकिन हम अधिक बैंक खाते प्रकार है कि भविष्य में ब्याज अर्जित कर सकते हैं हो सकता है, इसलिए हम एक InterestBearing इंटरफ़ेस है कि accrueInterest विधि बनाना चाहते हैं हो सकता है:

interface InterestBearing 
{ 
    public void accrueInterest(int amount); 
} 

class SavingsAccount extends AbstractBankAccount implements InterestBearing 
{ 
    public void deposit(int amount) 
    { 
     balance += amount; 
    } 

    public void withdraw(int amount) 
    { 
     balance -= amount; 
    } 

    public void accrueInterest(int amount) 
    { 
     balance += amount; 
    } 
} 

अब, अगर हम anothe बनाना चाहते:

तो, हम अब एक SavingsAccount वर्ग कि InterestBearing इंटरफेस को लागू करने से ब्याज प्राप्त कर सकते हैं कर सकते हैं आर प्रकार का खाता, PremiumSavingsAccount कहें, हम AbstractBankAccount का उप-वर्ग बना सकते हैं और InterestBearing इंटरफ़ेस को अन्य रुचि-रुचि खाते बनाने के लिए कार्यान्वित कर सकते हैं।

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

तो, वास्तव में एक ही स्थिति में एक साथ मिलकर काम करने और काम करने के लिए अमूर्त वर्गों और इंटरफेस दोनों के लिए जगहें हैं।

Answer 4

एक और:

है कि इंटरफेस और अमूर्त वर्गों को एक साथ का उपयोग कर का वर्णन जावा दुनिया पर एक लेख है:

Check this article on Java World

Answer 5

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

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

तो जावा सूची इंटरफ़ेस, और AbstractList सार आधार वर्ग इंटरफेस "प्रयास लागू करने की जरूरत को कम करने के लिए" प्रदान करता है ...

Answer 6

वहाँ कारणों की एक जोड़ी तुम क्यों एक कार्यान्वयन से मुक्त सार वर्ग पसंद कर सकते हैं एक इंटरफ़ेस पर:

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

लेकिन दूसरी ओर, इंटरफ़ेस जावा कीवर्ड क्लीनर स्रोत की अनुमति देता है।