जावा में सार वर्ग बनाम इंटरफ़ेस


87

मुझसे एक प्रश्न पूछा गया था, मैं अपने उत्तर की समीक्षा यहाँ करना चाहता था।

प्रश्न: किस परिदृश्य में इंटरफ़ेस लागू करने के बजाय एक अमूर्त वर्ग का विस्तार करना अधिक उचित है?

एक: अगर हम टेम्पलेट विधि डिजाइन पैटर्न का उपयोग कर रहे हैं।

क्या मैं सही हूँ ?

मुझे खेद है कि अगर मैं प्रश्न को स्पष्ट रूप से नहीं बता पा रहा था।
मुझे सार वर्ग और इंटरफ़ेस के बीच बुनियादी अंतर पता है।

1) आवश्यकता होने पर अमूर्त वर्ग का उपयोग करें, हमें एक विशिष्ट ऑपरेशन के लिए हर उपवर्ग में समान कार्यक्षमता को लागू करने की आवश्यकता है (विधि को लागू करें) और कुछ अन्य कार्यों के लिए अलग कार्यक्षमता (केवल विधि हस्ताक्षर)

2) इंटरफ़ेस का उपयोग करें यदि आपको हस्ताक्षर को एक ही (और कार्यान्वयन अलग) करने की आवश्यकता है ताकि आप इंटरफ़ेस कार्यान्वयन का अनुपालन कर सकें

3) हम अधिकतम एक सार वर्ग का विस्तार कर सकते हैं, लेकिन एक से अधिक इंटरफ़ेस लागू कर सकते हैं

प्रश्न को दोहराते हुए: क्या उपरोक्त उल्लिखित के अलावा कोई अन्य परिदृश्य हैं, जहां विशेष रूप से हमें अमूर्त वर्ग का उपयोग करने की आवश्यकता है (एक यह है कि टेम्पलेट विधि डिजाइन पैटर्न केवल इसी पर आधारित है)?

इंटरफ़ेस बनाम सार वर्ग

इन दोनों के बीच चयन करना वास्तव में इस बात पर निर्भर करता है कि आप क्या करना चाहते हैं, लेकिन सौभाग्य से हमारे लिए एरच गामा हमारी थोड़ी मदद कर सकता है।

जैसा कि हमेशा एक व्यापार बंद होता है, एक इंटरफ़ेस आपको आधार वर्ग के संबंध में स्वतंत्रता देता है, एक अमूर्त वर्ग आपको बाद में नए तरीकों को जोड़ने की स्वतंत्रता देता है । - एरच गामा

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

Abstract classesमुख्य रूप से उन वस्तुओं के लिए उपयोग किया जाना चाहिए जो निकट से संबंधित हैं। Interfacesअसंबंधित वर्गों के लिए सामान्य कार्यक्षमता प्रदान करने में बेहतर हैं।




यह डुप्लिकेट नहीं है। ओपी एक इंटरफ़ेस लागू करने के बजाय अमूर्त वर्ग का विस्तार करने के लिए जानना चाहता है । वह जानना नहीं चाहता कि अमूर्त वर्ग या इंटरफ़ेस कब लिखना है। उनका सार वर्ग और इंटरफ़ेस पहले से ही लिखा गया है। Hd जानना चाहता है कि विस्तार करना है या लागू करना है।
शिप्पू मोकादिम

1
@ shiplu.mokadd.im अंतर के बिना एक अंतर है। आप इसे विस्तारित किए बिना एक सार वर्ग का उपयोग नहीं कर सकते। यहां आपका नाइटपैकिंग पूरी तरह से निरर्थक लगता है।
लोर्ने

जवाबों:


86

जब इंटरफेस का उपयोग करने के लिए

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

जब सार वर्गों का उपयोग करें

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

कब करें दोनों का इस्तेमाल

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


मुझे लगता है कि ओपी यह जानना चाहता है कि एक इंटरफ़ेस लागू करने के बजाय अमूर्त वर्ग का विस्तार कब किया जाए
Shiplu Mokaddim

@ shiplu.mokadd.im वास्तव में ओपी ने एक बहुत विशिष्ट प्रश्न पूछा, जिसका उत्तर या तो 'हां' या 'नहीं' है।
लोरेन के मार्किस

4
आप सही हे। लेकिन एसओ में हम उचित स्पष्टीकरण के साथ हां / नहीं में जवाब देते हैं।
शिप्लू मोकादिम

1
@ shiplu.mokadd.im मैं यह नहीं देखता कि वह आपको अपने प्रश्न को गलत बताने का लाइसेंस कैसे देता है।
लोर्ने

केवल इस एक कथन के आधार पर If we are using template method design patternहम कह YESसकते हैंNO
दिव्यदर्शन

31

प्रश्न को दोहराते हुए: इन उल्लिखित के अलावा कोई अन्य परिदृश्य नहीं है, जहां विशेष रूप से हमें अमूर्त वर्ग का उपयोग करने की आवश्यकता है (एक यह है कि टेम्पलेट विधि डिजाइन पैटर्न केवल इस पर आधारित है)

हाँ, यदि आप JAXB का उपयोग करते हैं। इसे इंटरफेस पसंद नहीं है। आपको या तो अमूर्त कक्षाओं का उपयोग करना चाहिए या जेनरिक के साथ इस सीमा के आसपास काम करना चाहिए।

एक व्यक्तिगत ब्लॉग पोस्ट से :

इंटरफेस:

  1. एक वर्ग कई इंटरफेस को लागू कर सकता है
  2. एक इंटरफ़ेस बिल्कुल भी कोई कोड प्रदान नहीं कर सकता है
  3. एक इंटरफ़ेस केवल सार्वजनिक स्थैतिक अंतिम स्थिरांक को परिभाषित कर सकता है
  4. एक इंटरफ़ेस उदाहरण चर को परिभाषित नहीं कर सकता है
  5. एक नई विधि जोड़ने से कक्षाओं को लागू करने (डिजाइन रखरखाव) पर लहर प्रभाव पड़ता है
  6. JAXB इंटरफेस के साथ सौदा नहीं कर सकता
  7. एक इंटरफ़ेस एक अमूर्त वर्ग का विस्तार या कार्यान्वयन नहीं कर सकता है
  8. सभी इंटरफ़ेस विधियाँ सार्वजनिक हैं

सामान्य तौर पर, अनुबंधों को परिभाषित करने के लिए इंटरफेस का उपयोग किया जाना चाहिए (जो हासिल किया जाना है, न कि इसे कैसे प्राप्त किया जाए)।

सार वर्ग:

  1. एक वर्ग अधिकतम एक अमूर्त वर्ग में विस्तार कर सकता है
  2. एक अमूर्त वर्ग में कोड हो सकता है
  3. एक अमूर्त वर्ग स्थिर और उदाहरण दोनों को परिभाषित कर सकता है (अंतिम)
  4. एक अमूर्त वर्ग उदाहरण चर को परिभाषित कर सकता है
  5. मौजूदा अमूर्त वर्ग कोड के संशोधन का विस्तार कक्षाओं (कार्यान्वयन रखरखाव) पर लहर प्रभाव पड़ता है
  6. एक अमूर्त वर्ग में एक नई विधि जोड़ने से फैली हुई कक्षाओं पर कोई लहर प्रभाव नहीं पड़ता है
  7. एक सार वर्ग एक इंटरफ़ेस को लागू कर सकता है
  8. सार वर्ग निजी और संरक्षित तरीकों को लागू कर सकते हैं

अमूर्त वर्गों का उपयोग (आंशिक) कार्यान्वयन के लिए किया जाना चाहिए। वे एपीआई अनुबंध को लागू करने के तरीके को नियंत्रित करने के लिए एक साधन हो सकते हैं।


3
इंटरफ़ेस # 8 के लिए जावा 8 में, आपके पास defaultऔर staticतरीके भी हो सकते हैं ।
नौसिखिया उपयोगकर्ता

15

इंटरफ़ेस का उपयोग तब किया जाता है जब आपके पास परिदृश्य होता है कि सभी वर्गों में समान संरचना होती है लेकिन पूरी तरह से अलग कार्यक्षमता होती है।

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

लेख देखें: http://shoaibmk.blogspot.com/2011/09/abstract-class-is-class-which-cannot-be.html


9

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

आप एक निवेश बैंक में एक सॉफ्टवेयर डेवलपर हैं, और एक ऐसी व्यवस्था बनाने की जरूरत है, जो किसी बाजार में ऑर्डर दे। आपका इंटरफ़ेस एक ट्रेडिंग सिस्टम के सबसे सामान्य विचार को दर्शाता है ,

1) Trading system places orders
2) Trading system receives acknowledgements

और एक इंटरफ़ेस में कैद किया जा सकता है, ITradeSystem

public interface ITradeSystem{

     public void placeOrder(IOrder order);
     public void ackOrder(IOrder order);

}

अब बिक्री डेस्क पर और अन्य व्यावसायिक लाइनों के साथ काम करने वाले इंजीनियर अपने मौजूदा ऐप में ऑर्डर प्लेसमेंट कार्यक्षमता जोड़ने के लिए आपके सिस्टम के साथ इंटरफेस करना शुरू कर सकते हैं। और आपने अभी तक निर्माण शुरू नहीं किया है! यह इंटरफेस की शक्ति है।

तो आप आगे बढ़ते हैं और स्टॉक व्यापारियों के लिए सिस्टम का निर्माण करते हैं ; उन्होंने सुना है कि आपके सिस्टम में सस्ते स्टॉक खोजने की सुविधा है और वे इसे आज़माने के लिए बहुत उत्सुक हैं! आप इस व्यवहार को नामक विधि में कैप्चर करते हैं findGoodDeals(), लेकिन यह भी महसूस करते हैं कि बाजारों से जुड़ने में बहुत सारी गड़बड़ चीजें हैं। उदाहरण के लिए, आपको एक खोलना होगा SocketChannel,

public class StockTradeSystem implements ITradeSystem{    

    @Override 
    public void placeOrder(IOrder order);
         getMarket().place(order);

    @Override 
    public void ackOrder(IOrder order);
         System.out.println("Order received" + order);    

    private void connectToMarket();
       SocketChannel sock = Socket.open();
       sock.bind(marketAddress); 
       <LOTS MORE MESSY CODE>
    }

    public void findGoodDeals();
       deals = <apply magic wizardry>
       System.out.println("The best stocks to buy are: " + deals);
    }

ठोस कार्यान्वयन के लिए इन गन्दे तरीकों के बहुत सारे विकल्प हैं connectToMarket(), लेकिन findGoodDeals()क्या सभी व्यापारी वास्तव में इसकी परवाह करते हैं।

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

public abstract class ABCTradeSystem implements ITradeSystem{    

    public abstract void findGoodDeals();

    @Override 
    public void placeOrder(IOrder order);
         getMarket().place(order);

    @Override 
    public void ackOrder(IOrder order);
         System.out.println("Order received" + order);    

    private void connectToMarket();
       SocketChannel sock = Socket.open();
       sock.bind(marketAddress); 
       <LOTS MORE MESSY CODE>
    }

आपका स्टॉक ट्रेडिंग सिस्टम लागू findGoodDeals()करता है जैसा कि आपने पहले ही परिभाषित किया है,

public class StockTradeSystem extends ABCTradeSystem{    

    public void findGoodDeals();
       deals = <apply magic wizardry>
       System.out.println("The best stocks to buy are: " + deals);
    }

लेकिन अब एफएक्स व्हिज़ का बच्चा findGoodDeals()मुद्राओं के लिए केवल एक कार्यान्वयन प्रदान करके अपनी प्रणाली का निर्माण कर सकता है ; उसे सॉकेट कनेक्शन या यहां तक ​​कि इंटरफ़ेस विधियों को फिर से लागू करने की आवश्यकता नहीं है!

public class CurrencyTradeSystem extends ABCTradeSystem{    

    public void findGoodDeals();
       ccys = <Genius stuff to find undervalued currencies>
       System.out.println("The best FX spot rates are: " + ccys);
    }

एक इंटरफ़ेस के लिए प्रोग्रामिंग शक्तिशाली है, लेकिन इसी तरह के अनुप्रयोग अक्सर लगभग समान तरीकों से तरीकों को फिर से लागू करते हैं। एक अमूर्त वर्ग का उपयोग, इंटरफ़ेस की शक्ति को संरक्षित करते हुए, पुनर्मिलन से बचा जाता है।

नोट: कोई आश्चर्यचकित हो सकता है कि findGreatDeals()इंटरफ़ेस का हिस्सा क्यों नहीं है। याद रखें, इंटरफ़ेस एक ट्रेडिंग सिस्टम के सबसे सामान्य घटकों को परिभाषित करता है। एक अन्य इंजीनियर एक पूर्ण व्यापार प्रणाली विकसित कर सकते हैं, जहाँ वे अच्छे सौदे खोजने के बारे में परवाह नहीं करते हैं। इंटरफ़ेस यह गारंटी देता है कि बिक्री डेस्क उनके सिस्टम को भी इंटरफ़ेस कर सकता है, इसलिए यह आपके इंटरफेस को एप्लिकेशन अवधारणाओं जैसे "इंटरएक्टिव डील" के साथ उलझाना बेहतर नहीं है।


6

आपको कौन सा उपयोग करना चाहिए, अमूर्त वर्ग या इंटरफेस?

यदि इन कथनों में से कोई भी आपके उपयोग के मामले में लागू होता है, तो अमूर्त कक्षाओं का उपयोग करने पर विचार करें:

आप कई निकट संबंधित वर्गों के बीच कोड साझा करना चाहते हैं।

आप उम्मीद करते हैं कि आपके अमूर्त वर्ग का विस्तार करने वाले वर्गों के पास कई सामान्य तरीके या क्षेत्र हैं, या उन्हें सार्वजनिक (जैसे संरक्षित और निजी) के अलावा अन्य पहुँच संशोधक की आवश्यकता होती है।

आप गैर-स्थिर या गैर-अंतिम फ़ील्ड घोषित करना चाहते हैं। यह आपको उन तरीकों को परिभाषित करने में सक्षम बनाता है जो उस वस्तु की स्थिति तक पहुंच और संशोधित कर सकते हैं जो वे हैं।

यदि आपके उपयोग के मामले में इनमें से कोई भी कथन लागू होता है, तो इंटरफेस का उपयोग करने पर विचार करें:

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

आप एक विशेष डेटा प्रकार के व्यवहार को निर्दिष्ट करना चाहते हैं, लेकिन इसके व्यवहार को लागू करने के बारे में चिंतित नहीं हैं।

आप कई प्रकार की विरासत का लाभ उठाना चाहते हैं।

http://docs.oracle.com/javase/tutorial/java/IandI/abstract.html


4

जावा 8 रिलीज़ के साथ इंटरफ़ेस करने की नई क्षमताओं के साथ पिछले तीन वर्षों में चीजें बहुत बदल गई हैं।

इंटरफ़ेस पर oracle प्रलेखन पृष्ठ से:

एक इंटरफ़ेस एक संदर्भ प्रकार है, एक वर्ग के समान, जिसमें केवल स्थिरांक, विधि हस्ताक्षर, डिफ़ॉल्ट विधियाँ, स्थिर विधियाँ और शून्य प्रकार हो सकते हैं। विधि निकाय केवल डिफ़ॉल्ट विधियों और स्थिर विधियों के लिए मौजूद हैं।

जैसा कि आपने अपने प्रश्न में उद्धृत किया है, एब्सट्रैक्ट क्लास टेम्पलेट पद्धति पैटर्न के लिए सबसे उपयुक्त है जहां आपको कंकाल बनाना है। यहां इंटरफेस का उपयोग नहीं किया जा सकता।

इंटरफ़ेस पर अमूर्त वर्ग को पसंद करने के लिए एक और विचार:

आपके पास बेस क्लास में कार्यान्वयन नहीं है और केवल उप-वर्गों को अपने स्वयं के कार्यान्वयन को परिभाषित करना है। आपको इंटरफ़ेस के बजाय अमूर्त वर्ग की आवश्यकता है क्योंकि आप उप-वर्गों के साथ राज्य साझा करना चाहते हैं।

सार वर्ग स्थापित करता है "संबंधित वर्गों और इंटरफ़ेस प्रदान करता है के बीच एक संबंध है" असंबंधित वर्गों के बीच एक "क्षमता" है


आपके प्रश्न के दूसरे भाग के बारे में, जो जावा -8 रिलीज से पहले जावा सहित अधिकांश प्रोग्रामिंग भाषाओं के लिए मान्य है

जैसा कि हमेशा एक व्यापार बंद होता है, एक इंटरफ़ेस आपको आधार वर्ग के संबंध में स्वतंत्रता देता है, एक अमूर्त वर्ग आपको बाद में नए तरीके जोड़ने की स्वतंत्रता देता है। - एरच गामा

आप अपने कोड में बहुत सी अन्य चीजों को बदलने के बिना एक इंटरफ़ेस को बदल और बदल नहीं सकते

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

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

इंटरफ़ेस और अमूर्त वर्ग के बीच उनमें से एक का चयन करने के लिए, ओरेकल प्रलेखन पृष्ठ उद्धरण जो:

सार वर्ग इंटरफेस के समान हैं। आप उन्हें तुरंत नहीं कर सकते हैं, और उनके पास कार्यान्वयन के साथ या बिना घोषित तरीकों का मिश्रण हो सकता है। हालांकि, अमूर्त कक्षाओं के साथ, आप उन क्षेत्रों की घोषणा कर सकते हैं जो स्थिर और अंतिम नहीं हैं, और सार्वजनिक, संरक्षित, और निजी ठोस तरीकों को परिभाषित करते हैं।

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

इन संबंधित प्रश्नों का संदर्भ लें और अधिक विवरण:

इंटरफ़ेस बनाम सार वर्ग (सामान्य ऊ)

मुझे एक इंटरफ़ेस और एक सार वर्ग के बीच अंतर कैसे समझाया जाना चाहिए?

संक्षेप में: शेष अब इंटरफेस की ओर अधिक झुक रहा है

क्या उपरोक्त उल्लिखित लोगों के अलावा कोई अन्य परिदृश्य हैं, जहां विशेष रूप से हमें अमूर्त वर्ग का उपयोग करने की आवश्यकता है (एक यह है कि टेम्पलेट विधि डिजाइन पैटर्न वैचारिक रूप से केवल इस पर आधारित है)?

कुछ डिज़ाइन पैटर्न टेम्प्लेट विधि पैटर्न के अलावा एब्स्ट्रैक्ट क्लासेस (इंटरफेस से अधिक) का उपयोग करते हैं।

रचनात्मक पैटर्न:

Abstract_factory_pattern

संरचनात्मक पैटर्न:

Decorator_pattern

स्वभावजन्य तरीका:

Mediator_pattern


यह: "सार वर्ग स्थापित करता है" एक "संबंधित वर्गों और इंटरफ़ेस प्रदान करता है के बीच संबंध है" "असंबंधित वर्गों के बीच क्षमता है।"
गेब्रियल

3

आप सही नहीं हैं। कई परिदृश्य हैं। इसे 8-शब्द के नियम से कम करना संभव नहीं है।


1
जब तक आप अस्पष्ट हैं जैसे; जब भी आप एक इंटरफ़ेस का उपयोग कर सकते हैं;)
पीटर लॉरी

@PeterLawrey हाँ, परिपत्र तर्क को धीमा न होने दें ;-)
लोर्ने के मार्किस

यह सब के बाद "स्टैक ओवरफ्लो" है। ;) मेरा कहना है कि यदि आप सरल इंटरफ़ेस का उपयोग कर सकते हैं, तो ऐसा करें। अन्यथा आपके पास अमूर्त वर्ग का उपयोग करने के अलावा कोई विकल्प नहीं है। मैं इसे बहुत जटिल नहीं देखता।
पीटर लॉरी

मुझे लगता है कि आप एक अधिक रचनात्मक विचार प्रदान कर सकते हैं। जैसे कुछ प्रतिनिधि परिदृश्यों के बारे में बात करते हैं /
Adams.H

3

सबसे छोटा उत्तर यह है कि अमूर्त वर्ग का विस्तार करें जब कुछ प्रकार की कार्यक्षमताएं पहले से ही इसमें लागू हैं।

यदि आप इंटरफ़ेस को लागू करते हैं तो आपको सभी विधि को लागू करना होगा। लेकिन अमूर्त वर्ग संख्या के तरीकों के लिए आपको लागू करने की आवश्यकता कम हो सकती है।

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


शुद्ध वर्चुअल फंक्शन के लिए अतिरिक्त संदर्भ सार वर्ग और इंटरफ़ेस के कन्वर्जेंस के बारे में और अधिक जानकारी जोड़ देगा , Pure virtual functions can also be used where the method declarations are being used to define an interface - similar to what the interface keyword in Java explicitly specifies. In such a use, derived classes will supply all implementations. In such a design pattern, the abstract class which serves as an interface will contain only pure virtual functions, but no data members or ordinary methods. भाग (1/2)
अभिजीत

भाग (2/2) सार वर्ग और इंटरफ़ेस का विचलनno data members or ordinary methods [सार कक्षा में] ऊपर की अंतिम पंक्ति द्वारा समझाया गया है ।
अभिजीत

3

मेरी राय में, बुनियादी अंतर यह है कि an interface can't contain non abstract methods while an abstract class can। इसलिए यदि उपवर्ग एक सामान्य व्यवहार को साझा करते हैं, तो यह व्यवहार सुपर क्लास में लागू किया जा सकता है और इस प्रकार उपवर्गों में विरासत में मिला है

इसके अलावा, मैंने "सॉफ्टवेयर आर्किटेक्चर डिजाइन ppatterns in java" पुस्तक से निम्नलिखित उद्धृत किया

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


2

सार वर्ग दो महत्वपूर्ण पहलुओं में इंटरफेस से अलग हैं

  • वे चुने हुए तरीकों के लिए डिफ़ॉल्ट कार्यान्वयन प्रदान करते हैं (जो आपके उत्तर द्वारा कवर किया गया है)
  • अमूर्त वर्गों में राज्य (उदाहरण के चर) हो सकते हैं - इसलिए यह एक और स्थिति है जिसे आप इंटरफेस के स्थान पर उपयोग करना चाहते हैं

मैं पूरा करूंगा कि इंटरफेस में चर हो सकते हैं लेकिन वे डिफ़ॉल्ट रूप से अंतिम हैं।
टॉमाज़ मूलारस्क

1

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


0

Abstract classes should be extended when you want to some common behavior to get extended। अमूर्त सुपर क्लास में सामान्य व्यवहार होगा और सार पद्धति / विशिष्ट व्यवहार को परिभाषित करेगा जिसे उप-वर्गों को लागू करना चाहिए।

Interfaces allows you to change the implementation anytime allowing the interface to be intact


0

यह मेरी समझ है, आशा है कि यह मदद करता है

सार वर्ग:

  1. सदस्य चर हो सकते हैं जो विरासत में मिले हैं (इंटरफेस में नहीं किए जा सकते)
  2. कंस्ट्रक्टर हो सकते हैं (इंटरफेस नहीं हो सकता)
  3. इसकी विधियाँ कोई भी दृश्यता हो सकती हैं (जैसे: निजी, संरक्षित, आदि - जबकि सभी इंटरफ़ेस विधियाँ सार्वजनिक हैं)
  4. परिभाषित तरीके हो सकते हैं (कार्यान्वयन के साथ तरीके)

इंटरफेस:

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

0

अमूर्त और इंटरफ़ेस का उपयोग:

एक का "ई-ए-रिलेशनशिप" है और दूसरे का "हस-ए-रिलेशनशिप" है

डिफ़ॉल्ट गुणों को अमूर्त में सेट किया गया है और अतिरिक्त गुणों को इंटरफ़ेस के माध्यम से व्यक्त किया जा सकता है।

उदाहरण: -> इंसानों में हमारे कुछ डिफ़ॉल्ट गुण होते हैं जो खा रहे हैं, सो रहे हैं आदि लेकिन अगर किसी के पास तैरने, खेलने आदि जैसी कोई अन्य गतिविधि है, तो उन्हें इंटरफ़ेस द्वारा व्यक्त किया जा सकता है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.