क्या एक अमूर्त वर्ग और इंटरफ़ेस दोनों होने का कोई लाभ है?

Question

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

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

क्या अमूर्त वर्ग और इंटरफ़ेस दोनों को रखने के लिए कोई लाभ है?

धन्यवाद!

Answer 1

निश्चित रूप से। आइए एक ठोस उदाहरण के बारे में सोचें।

कहें कि हमारे पास एक अमूर्त वर्ग Animal है। कहें, हम कुछ सबक्लास Cat, Dog, Mosquito, और Eagle बनाते हैं। हम अपने Eat(), Breathe(), Sleep() अमूर्त वर्ग Animal के तरीकों को कार्यान्वित कर सकते हैं।

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

IFly इंटरफ़ेस को लागू करने के लिए Fly() विधि हो सकती है। दोनों Mosquito और Eagle कक्षाएं दोनों सार वर्ग Animal की उपवर्गों हो सकता है और इंटरफेस IFly को लागू करने और दो वर्गों के बीच अजीब ancenstral संबंध किसी प्रकार बिना Eat(), Breathe(), Sleep() और Fly() करने में सक्षम हो सकते हैं।

Answer 2

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

संपादित करें: मैं कई अमूर्त कक्षाओं के साथ विरासत कोड पर काम करता हूं। यदि मेरे पास समय है, तो मैं इंटरफेस जोड़ूंगा, (और संभवतः रिक्त सार तत्वों को हटा दूंगा)। क्योंकि इंटरफेस के साथ काम करने से संभावनाएं काफी बढ़ जाती हैं। और वे इंटरफ़ेस को बिल्कुल परिभाषित करके उनके नाम का सम्मान करते हैं।

Answer 3

मैं आमतौर पर सार वर्गों के खिलाफ कोड जब यह समझ में आता है और लागू करने (और एक बाहरी ठेके विधानसभा/पुस्तकालय में बनाने) हर कक्षा में एक इंटरफेस (सार या नहीं) तो मैं और अधिक आसानी से विंडोज संचार फाउंडेशन या inversion of control जब आवश्यक लागू कर सकते हैं (जो लगभग हमेशा मजाक करने के लिए है)। यह मेरे लिए दूसरी प्रकृति बन गया है।

Answer 4

बिल्कुल। इंटरफ़ेस हमेशा जाने का सही तरीका है - इस तरह से कुछ भी इसे कार्यान्वित कर सकता है (जिसमें कुछ भी पहले से ही माता-पिता है)।

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

Answer 5

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

Answer 6

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

Answer 7

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

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

हालांकि, मैं सुझाव दूंगा कि आपके विशेष मामले में आप जिस डिजाइन पैटर्न का उपयोग कर रहे हैं उसकी समीक्षा कर सकते हैं। ऐसा लगता है कि बहुत सारे "लॉगऑन-टाइप" वर्ग हैं।

Answer 8

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

आप विभिन्न प्रकार के तरीकों के साथ एक नया इंटरफेस बनाकर सबक्लास की कार्यक्षमता बढ़ा सकते हैं।

Answer 9

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

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

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

Answer 10

मान लिया जाये कि आप विशेष रूप से पूछ रहे हैं जब इंटरफेस और अमूर्त वर्ग समान हस्ताक्षर है ...

...(यदि इंटरफेस के सदस्य अमूर्त वर्ग के सदस्यों से किसी भी तरह से अलग हैं तो निश्चित रूप से उत्तर हाँ है, दोनों की आवश्यकता हो सकती है)

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