क्या अमूर्त वर्ग / विधियाँ अप्रचलित हैं?

Question

मैं बहुत सारे अमूर्त वर्ग / तरीके बनाता था। फिर मैंने इंटरफेस का इस्तेमाल शुरू किया।

अब मुझे यकीन नहीं है कि अगर इंटरफेस अमूर्त वर्गों को अप्रचलित नहीं कर रहे हैं।

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

तो, क्या अमूर्त वर्ग / तरीके अप्रचलित हैं?

Comments

कैसे के बारे में अगर आपकी पसंद की प्रोग्रामिंग भाषा इंटरफेस का समर्थन नहीं करती है? मुझे लगता है कि यह C ++ का मामला है।

— बर्नार्ड

@Bernard: C ++, एक अमूर्त वर्ग है सभी लेकिन नाम में एक इंटरफेस। यह कि वे 'शुद्ध' इंटरफेस से अधिक कर सकते हैं, नुकसान नहीं है।

— gbjbaanb

@ जीबीजैनब: मुझे लगता है। मुझे उन्हें इंटरफेस के रूप में उपयोग करने की याद नहीं है, बल्कि डिफ़ॉल्ट कार्यान्वयन प्रदान करने के लिए।

— बर्नार्ड

वस्तु संदर्भों की "मुद्रा" हैं। आम तौर पर बोलते हुए वे बहुरूपी व्यवहार के मूल हैं। सार कक्षाएं एक अलग उद्देश्य पर काम करती हैं जिसे डेडलिंक ने पूरी तरह से समझाया।

— जिगी

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

— जैक वी।

Answer 1

नहीं।

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

यह भी अनुक्रमिक युग्मन को कम करने का एक बहुत अच्छा तरीका है। अमूर्त विधि / कक्षाओं के बिना, आप टेम्पलेट विधि पैटर्न को लागू नहीं कर सकते। मेरा सुझाव है कि आप इस विकिपीडिया लेख को देखें: http://en.wikipedia.org/wiki/Template_method_pattern

Comments

@deadalnix टेम्पलेट विधि पैटर्न काफी खतरनाक हो सकता है। आप आसानी से अत्यधिक युग्मित कोड के साथ समाप्त हो सकते हैं, और "बस एक और मामले" को संभालने के लिए टेम्पर्ड एब्स्ट्रैक्ट क्लास का विस्तार करने के लिए कोड हैक करना शुरू कर सकते हैं।

— क्वांट_देव

यह एक विरोधी पैटर्न की तरह लगता है। आप इंटरफ़ेस के खिलाफ रचना के साथ बिल्कुल वही चीज़ प्राप्त कर सकते हैं। कुछ सार विधियों के साथ आंशिक वर्गों पर भी समान बात लागू होती है। इसके बाद ग्राहक कोड को उप-वर्ग के लिए मजबूर करने और उन्हें ओवरराइड करने के लिए, आपको कार्यान्वयन को इंजेक्ट किया जाना चाहिए । देखें: en.wikipedia.org/wiki/Composition_over_inheritance#Benefits

— back2dos

यह क्रमिक युग्मन को कम करने के लिए सभी को नहीं समझाता है। मैं इस बात से सहमत हूं कि इस लक्ष्य को प्राप्त करने के लिए कई तरीके मौजूद हैं, लेकिन कृपया, उस समस्या का जवाब दें जिसके बारे में आप आँख बंद करके किसी सिद्धांत को लागू कर रहे हैं। आप कार्गो पंथ प्रोग्रामिंग कर रहे हैं यदि आप यह नहीं बता सकते कि यह वास्तविक समस्या से संबंधित क्यों है।

— deadalnix

@deadalnix: यह कहना कि अनुक्रमिक युग्मन को टेम्पलेट पैटर्न के साथ सबसे कम किया जाता है, कार्गो पंथ प्रोग्रामिंग है (राज्य / रणनीति / कारखाने के पैटर्न का उपयोग सिर्फ काम कर सकता है), जैसा कि यह धारणा है कि इसे हमेशा कम किया जाना चाहिए। अनुक्रमिक युग्मन अक्सर किसी चीज पर बहुत महीन दानेदार नियंत्रण को उजागर करने का एक मात्र परिणाम होता है, जिसका अर्थ व्यापार-बंद कुछ नहीं होता है। इसका मतलब यह नहीं है कि मैं एक रैपर नहीं लिख सकता जिसमें रचना का उपयोग करके अनुक्रमिक युग्मन नहीं है। वास्तव में, यह बहुत आसान बनाता है।

— बैक 2 डोस

जावा में अब इंटरफेस के लिए डिफ़ॉल्ट कार्यान्वयन है। क्या इसका जवाब बदल जाता है?

— raptortech97

Answer 2

एक अमूर्त विधि मौजूद है इसलिए आप इसे अपने बेस क्लास के भीतर से कॉल कर सकते हैं लेकिन इसे एक व्युत्पन्न क्लास में लागू कर सकते हैं। तो आपका आधार वर्ग जानता है:

public void DoTask()
{
    doSetup();
    DoWork();
    doCleanup();
}

protected abstract void DoWork();

सेटअप और सफाई गतिविधियों के बारे में जाने बिना व्युत्पन्न वर्ग के बीच के पैटर्न में छेद को लागू करने के लिए यह एक अच्छा तरीका है। अमूर्त तरीकों के बिना, आपको व्युत्पन्न वर्ग को लागू करने DoTaskऔर कॉल करने base.DoSetup()और base.DoCleanup()हर समय याद रखने पर भरोसा करना होगा ।

संपादित करें

इसके अलावा, टेम्पलेट विधि पैटर्न के लिए एक लिंक पोस्ट करने के लिए डेडलिंक के लिए धन्यवाद , जो कि मैंने ऊपर वर्णित किया है, वास्तव में नाम जानने के बिना। :)

Comments

+1, मैं डेडलिंक के आपके उत्तर को पसंद करता हूं। ' ध्यान दें कि आप प्रतिनिधियों (C # में) का उपयोग करके अधिक सीधे-आगे के तरीके से एक टेम्प्लेट विधि लागू कर सकते हैं:public void DoTask(Action doWork)

— Joh

@ जो - सच है, लेकिन यह आपके एपीआई पर निर्भर करता है, उतना अच्छा नहीं है। यदि आपका आधार वर्ग है Fruitऔर आपका व्युत्पन्न वर्ग है Apple, तो आप कॉल करना चाहते हैं myApple.Eat(), नहीं myApple.Eat((a) => howToEatApple(a))। इसके अलावा, आपको Appleकॉल करने की आवश्यकता नहीं है base.Eat(() => this.howToEatMe())। मुझे लगता है कि यह केवल एक अमूर्त विधि को ओवरराइड करने के लिए क्लीनर है।

— स्कॉट व्हिटलॉक

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

— जोहल

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

— टोनी

Answer 3

नहीं, वे अप्रचलित नहीं हैं।

वास्तव में, एब्सट्रैक्ट क्लासेस / मेथड्स और इंटरफेस के बीच एक अस्पष्ट लेकिन मौलिक अंतर है।

यदि वर्गों का सेट जिसमें इनमें से किसी एक का उपयोग किया जाना है, तो उनके पास एक सामान्य व्यवहार है जो वे साझा करते हैं (संबंधित कक्षाएं, मेरा मतलब है), फिर सार वर्ग / विधियों के लिए जाएं।

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

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

उदाहरण: गाय, बेंच, कार, टेलीस्कोप-संबंधित वर्ग नहीं, लेकिन एक सरणी में उन्हें छांटने के लिए Isortable हो सकता है।

इस अंतर को आमतौर पर नजरअंदाज किया जाता है जब एक बहुरूपी परिप्रेक्ष्य से संपर्क किया जाता है। लेकिन मुझे व्यक्तिगत रूप से लगता है कि ऐसी स्थितियां हैं, जिनमें से एक ऊपर वर्णित कारण के लिए एक दूसरे की तुलना में उपयुक्त है।

Answer 4

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

public abstract class Frobber
{
    private Frobber() {}
    public abstract void Frob(Frotz frotz);
    private class GreenFrobber : Frobber
    { ... }
    private class RedFrobber : Frobber
    { ... }
    public static Frobber GetFrobber(bool b) { ... } // return a green or red frobber
}

public sealed class Frotz
{
    public void Frobbit(Frobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

मुझे गारंटी है कि केवल दो कोड पथ हैं जिनकी मुझे जांच करने की आवश्यकता है। फ्रोबबिट के लेखक इस तथ्य पर भरोसा कर सकते हैं कि फ्रोबेर लाल या हरा है।

अगर इसके बजाय हम कहते हैं:

public interface IFrobber
{
    void Frob(Frotz frotz);
}
public class GreenFrobber : IFrobber
{ ... }
public class RedFrobber : Frobber
{ ... }

public sealed class Frotz
{
    public void Frobbit(IFrobber frobber)
    {
         ...
         frobber.Frob(this);
         ...
    }
}

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

सार कक्षाएं आपको इन सभी समस्याओं से बचने की अनुमति देती हैं; उन्हें इस्तेमाल करें!

Comments

आप जिस समस्या से बात करते हैं, उसे बीजीय डेटा प्रकारों का उपयोग करके हल किया जाना चाहिए, न कि झुकने वाली कक्षाओं के बजाय एक बिंदु पर जहां वे खुले या बंद सिद्धांत का उल्लंघन करते हैं।

— बैक 2 डोस

सबसे पहले, मैंने कभी नहीं कहा कि यह अच्छा या नैतिक है । आपने वह मेरे मुंह में डाल दिया। दूसरी बात (मेरे वास्तविक बिंदु होने के नाते): यह एक गायब भाषा की सुविधा के लिए एक खराब बहाने के अलावा और कुछ नहीं है। अंत में, सार वर्गों के बिना एक समाधान है: pastebin.com/DxEh8Qfz । इसके विपरीत, आपके दृष्टिकोण नेस्टेड और अमूर्त वर्गों का उपयोग करते हैं, सभी को फेंक देते हैं लेकिन कोड को एक बड़ी मिट्टी की गेंद में एक साथ सुरक्षा की आवश्यकता होती है। कोई अच्छा कारण नहीं है कि RedFrobber या GreenFrobber को उन बाधाओं से बंधा होना चाहिए जिन्हें आप लागू करना चाहते हैं। यह बिना किसी लाभ के कई फैसलों में युग्मन और ताले को बढ़ाता है।

— back2dos

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

— ग्रू जूल

"एक बुनियादी अंतर है [...] इंटरफेस बहुत कम विश्वसनीय हैं [...] अमूर्त वर्गों की तुलना में"। मैं असहमत हूं, आपने अपने कोड में जो अंतर स्पष्ट किया है, वह एक्सेस प्रतिबंधों पर निर्भर करता है, जो मुझे नहीं लगता कि इंटरफेस और अमूर्त वर्गों के बीच काफी अंतर करने का कोई कारण है। C # में ऐसा हो सकता है, लेकिन सवाल भाषा-अज्ञेय का है।

— जोह

@ back2dos: मैं केवल यह बताना चाहूंगा कि एरिक का समाधान वास्तव में, एक बीजीय डेटा प्रकार का उपयोग करता है: एक सार वर्ग एक योग प्रकार है। एक अमूर्त पद्धति को कॉल करना वैरिएंट के सेट पर मिलते-जुलते पैटर्न के समान है।

— रोड्रिक चैपमैन

Answer 5

आप इसे स्वयं कहते हैं:

आपको इसमें कुछ कार्यान्वयन के साथ एक सार वर्ग की आवश्यकता है? एक इंटरफ़ेस बनाएं, एक क्लास बनाएं। वर्ग को सम्मिलित करें, इंटरफ़ेस लागू करें

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

Comments

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

— सोजेरड जूल

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

— बिल के

Answer 6

जैसा कि मैंने @deadnix पोस्ट पर टिप्पणी की: आंशिक कार्यान्वयन एक विरोधी पैटर्न है, इस तथ्य के बावजूद कि टेम्पलेट पैटर्न उन्हें औपचारिक करता है।

टेम्पलेट पैटर्न के इस विकिपीडिया उदाहरण के लिए एक साफ समाधान :

interface Game {
    void initialize(int playersCount);
    void makePlay(int player);
    boolean done();
    void finished();
    void printWinner();
}
class GameRunner {
    public void playOneGame(int playersCount, Game game) {
        game.initialize(playersCount);
        int j = 0;
        for (int i = 0; !game.finished(); i++)
             game.makePlay(i % playersCount);
        game.printWinner();
    }
} 
class Monopoly implements Game {
     //... implementation
}

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

Comments

+1। एक साइड-नोट के रूप में: "आंशिक कार्यान्वयन एक विरोधी पैटर्न है, इस तथ्य के बावजूद कि टेम्पलेट पैटर्न उन्हें औपचारिक बनाता है।" विकिपीडिया पर विवरण पैटर्न को सफाई से परिभाषित करता है, केवल कोड उदाहरण "गलत" है (इस अर्थ में कि यह विरासत का उपयोग करता है जब इसकी आवश्यकता नहीं होती है और एक सरल विकल्प मौजूद है, जैसा कि ऊपर सचित्र है)। दूसरे शब्दों में, मुझे नहीं लगता कि पैटर्न को ही दोष देना है, केवल उसी तरह जिस तरह लोग इसे लागू करते हैं।

— जोह

Answer 7

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

Comments

-1। मुझे समझ नहीं आता कि "जेनेरिक कोड बनाम वंशानुक्रम" का सवाल क्या है। आपको यह स्पष्ट करना चाहिए या उचित होना चाहिए कि "एब्स्ट्रैक्ट क्लासेस के इंटरफेस पर महत्वपूर्ण लाभ क्यों हैं"।

— जोह

Answer 8

सार वर्ग इंटरफेस नहीं हैं। वे ऐसी कक्षाएं हैं जो त्वरित नहीं हो सकतीं।

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

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

उदाहरण के लिए, इस वर्ग को देखते हुए

public abstract class Frobber {
    public abstract void Frob();

    public abstract boolean IsFrobbingNeeded { get; }

    public void FrobUntilFinished() {
        while (IsFrobbingNeeded) {
            Frob();
        }
    }
}

आप एक वर्ग है कि न तो इस आधार कार्यक्षमता कैसे लागू होता Frob()है और न ही IsFrobbingNeeded?

Comments

एक इंटरफ़ेस को तत्काल भी नहीं किया जा सकता है।

— सोजेरड जूल

@Sjoerd: लेकिन आपको साझा कार्यान्वयन के साथ बेस क्लास की आवश्यकता है; यह एक इंटरफ़ेस नहीं हो सकता।

— विन्यासकर्ता

Answer 9

मैं सर्वलेट ढाँचे का निर्माता हूँ जहाँ अमूर्त वर्ग आवश्यक भूमिका निभाते हैं। मैं और अधिक कहूंगा, मुझे अर्ध सार विधियों की आवश्यकता है, जब एक विधि को 50% मामलों में ओवरराइड करने की आवश्यकता होती है और मैं संकलक से चेतावनी देखना चाहूंगा कि उस विधि के बारे में ओवरराइड नहीं किया गया था। मैं एनोटेशन जोड़कर समस्या का समाधान करता हूं। अपने प्रश्न पर वापस लौटते हुए, अमूर्त वर्गों और इंटरफेस के दो अलग-अलग उपयोग के मामले हैं, और कोई भी अब तक अप्रचलित नहीं है।

Answer 10

मुझे नहीं लगता कि वे इंटरफेस द्वारा ऑब्जर्वेट किए गए हैं, लेकिन उन्हें रणनीति पैटर्न द्वारा पालन किया जा सकता है।

अमूर्त वर्ग का प्राथमिक उपयोग कार्यान्वयन के एक भाग को स्थगित करना है; कहने के लिए, "कक्षा के कार्यान्वयन के इस हिस्से को अलग बनाया जा सकता है"।

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

Answer 11

मैंने आम तौर पर एबीसी की तुलना में शुद्ध इंटरफेस के साथ दूर, बहुत अधिक रखरखाव समस्याओं का सामना किया है, यहां तक ​​कि एबीसी कई विरासत के साथ उपयोग किया जाता है। YMMV - डननो, शायद हमारी टीम ने उन्हें अपर्याप्त रूप से इस्तेमाल किया।

उस ने कहा, अगर हम एक वास्तविक दुनिया सादृश्य का उपयोग करते हैं, तो शुद्ध इंटरफेस के लिए कार्यक्षमता और राज्य से पूरी तरह से कितना उपयोग है? यदि मैं एक उदाहरण के रूप में USB का उपयोग करता हूं, तो यह एक यथोचित स्थिर इंटरफ़ेस है (मुझे लगता है कि हम अभी USB 3.2 पर हैं, लेकिन इसने पीछे की संगतता भी बनाए रखी है)।

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

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

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

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

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