एक वर्ग पर कितने अंतर हैं? [बन्द है]

Question

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

Comments

खैर, यह किसी भी तरह से संदिग्ध है। यदि कक्षा में 23 विधियाँ हैं, जो सभी एक ही ज़िम्मेदारी का निर्वाह करती हैं (सभी वर्गों को इतने तरीकों की आवश्यकता नहीं है, लेकिन यह असंभव नहीं है - खासकर यदि अधिकांश अन्य विधियों के आसपास तीन-पंक्ति सुविधा आवरण हैं), तो आपके पास बहुत ही महीन-महीन इंटरफेस है; )

विचाराधीन वर्ग एक प्रकार की इकाई है और इंटरफेस ज्यादातर संपत्तियों के लिए हैं। उनमें से 113 हैं और केवल चार विधियाँ हैं।

— जोनास एल्फ्रॉस्टेम

मैंने सोचा था कि इंटरफेस अनिवार्य रूप से सांख्यिकीय-संकलित भाषाओं में बतख टाइपिंग के लिए उपयोग किया जाता है। समस्या क्या है? :)

— राख

बस एक सवाल: क्या इस इकाई के प्रत्येक उदाहरण के लिए सभी 113 संपत्तियां आबाद हैं? या क्या यह किसी प्रकार के "सामान्य निकाय" का उपयोग विभिन्न संदर्भों में केवल कुछ गुणों से भरा हुआ है?

— डेविड

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

— स्टीफन ग्रॉस

Answer 1

रॉयल परिवार: वे कुछ भी विशेष रूप से पागल नहीं करते हैं, लेकिन उनके पास एक अरब का खिताब है और वे किसी भी तरह अधिकांश अन्य रॉयल्स से संबंधित हैं।

Comments

:-)))))))))))))

— एमिलियो गरवाग्लिया

मुझे तनाव हैsomehow

— वुल्फ

Answer 2

मैं प्रस्तुत करता हूं कि इस विरोधी पैटर्न को जैक ऑफ ऑल ट्रेड्स, या शायद बहुत सारे हाट का नाम दिया जाए।

Comments

स्विस आर्मी नाइफ के बारे में कैसे?

— FrustratedWithFormsDesigner

ऐसा लगता है कि इस शब्द का उपयोग पहले से ही कई तरीकों के साथ इंटरफेस के लिए किया जाता है :-) हालांकि यह यहां भी समझ में आता है।

— जलयान 14

@FrustratedWithFormsDesigner एक स्विस आर्मी नाइफ को IValue नाम के एक इंटरफ़ेस का बुरा स्वाद कभी नहीं होगा जिसमें 30 गुण होते हैं जिनमें से 20 नए संशोधक कीवर्ड से पहले होते हैं।

— जोनास एलफ्रॉस्टेम

+1 फॉर टू हैट

— हेट

एक स्विस सेना चाकू पुन: उपयोग का एक मॉडल है। यानी एक एकल "ब्लेड" तरीकों का प्रदर्शन कर सकता है इसलिए यह शायद एक बुरा सादृश्य है!

— जेम्स एंडरसन

Answer 3

अगर मुझे इसे कोई नाम देना होता, तो मुझे लगता है कि मैं इसे हाइड्रा कहूंगा :

ग्रीक पौराणिक कथाओं में, लर्नियन हाइड्रा (ग्रीक: ίρναὝδα Ὕδρα) एक प्राचीन नामहीन नाग-नागिन की तरह का पानी का जानवर था, जिसमें सरीसृप के लक्षण थे, (जैसा कि इसके नाम से पता चलता है, जिसमें कई सिर थे - कवि, फूलदान-चित्रकारों की तुलना में अधिक प्रमुख हैं। पेंट, और प्रत्येक सिर काट के लिए यह दो और बढ़ गया - और जहरीली सांस इतनी वायरल थी कि यहां तक ​​कि उसके ट्रैक भी घातक थे।

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

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

public void CreateWidget(IPartLocator locator, int widgetTypeId)
{
    var partsNeeded = locator.GetPartsForWidget(widgetTypeId);
    return ((IAssembler)locator).BuildWidget(partsNeeded);
}

जब यह स्पष्ट हो जाता है कि इस कोड के बारे में कुछ गड़बड़ है, लेकिन ऐसा होने की संभावना अधिक "प्रमुखों" के साथ बढ़ती है, क्योंकि डेवलपर्स सहजता से जानते हैं कि वे हमेशा एक ही प्राणी के साथ काम कर रहे हैं।

सौभाग्य कभी भी एक वस्तु पर कोई रखरखाव कर रहा है जो 23 इंटरफेस को लागू करता है। आपके द्वारा प्रक्रिया में संपार्श्विक क्षति का कारण नहीं होने की संभावना कम है।

Answer 4

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

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

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

Comments

मुझे यकीन नहीं है कि यह ईश्वर वस्तु विरोधी पैटर्न है, क्योंकि ईश्वर किसी भी इंटरफेस से विवश नहीं है। इतने सारे अवरोधों के कारण विवश होकर भगवान की सर्वशक्तिमानता को कम किया जा सकता है। ;) शायद यह एक चिमीरा वस्तु है?

— FrustratedWithFormsDesigner

भगवान के कई चेहरे हैं, और कई लोगों के लिए कई चीजें हो सकती हैं। यदि संयुक्त इंटरफेस की कार्यक्षमता वस्तु को "सभी-जानने वाला" बनाती है तो यह वास्तव में भगवान को विवश नहीं करता है, क्या यह है?

— कीथ्स

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

— FrustratedWithFormsDesigner

दुख होता है कि आप सोचते हैं कि यह मैं ही था जिसने क्लास बनाई।

— जोनास एल्फ्रॉस्टेम

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

— कीथ्स

Answer 5

२३ बस एक नंबर है! सबसे अधिक संभावना परिदृश्य में, यह अलार्म के लिए पर्याप्त उच्च है। हालाँकि, यदि हम पूछें, कि "टैग-प्रतिरूप" कहे जाने वाले एक टैग को प्राप्त करने से पहले किस विधि / इंटरफेस की अधिकतम संख्या है? यह 5 या 10 या 25 है? आपको पता है कि संख्या वास्तव में एक उत्तर नहीं है क्योंकि यदि 10 अच्छा है, तो 11 भी हो सकते हैं - और उसके बाद कोई भी पूर्णांक।

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

दूसरी ओर, अपेक्षाकृत छोटे आकार का कोड जो कुछ घंटों में और बाहर पढ़ने की उम्मीद कर सकता है- अभी भी जटिल हो सकता है। जब मुझे लगता है कि यह कोड (अनावश्यक रूप से) जटिल है।

ऑब्जेक्ट-ओरिएंटेड डिज़ाइन के ज्ञान का हर टुकड़ा यहाँ "जटिल" को परिभाषित करने के लिए रखा जा सकता है, लेकिन मैं यहाँ दिखाने के लिए प्रतिबंधित करूँगा जब "इतने सारे तरीके" जटिलता के संकेत हैं।

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

2. बहुत से दोहराए जाते हैं (तोड़ते हुए) जब ऐसे तरीके जिनके समान नाम होते हैं लेकिन काम का विरोधाभास करते हैं - या समान कार्यक्षमता वाले नामों का खंडन करते हैं। कई बार विभिन्न अनुप्रयोगों के लिए थोड़ा अलग इंटरफेस का समर्थन करने के लिए कोड विकसित होते हैं।

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

4. (में) एपीआई की निरंतरता जब मैं book_a_ticket करना () - मैं एक टिकट बुक! यह बहुत ही सरल है, चाहे कितनी भी जाँच और प्रक्रिया हो जाए। अब यह जटिल हो जाता है जब समय प्रवाह इस पर प्रभाव डालना शुरू कर देता है। आमतौर पर एक "खोज" और संभव उपलब्ध / अनुपलब्ध स्थिति की अनुमति देता है, फिर बैक-एन-आगे को कम करने के लिए आप टिकट के अंदर कुछ संदर्भ बिंदुओं को सहेजना शुरू करते हैं फिर टिकट बुक करने का संदर्भ देते हैं। खोज केवल कार्यक्षमता नहीं है- कई "साइड कार्यक्षमता" के बाद चीजें बदतर हो जाती हैं। इस प्रक्रिया में book_a_ticket () का अर्थ book_that_ticket () है! और जो अकल्पनीय रूप से जटिल हो सकता है।

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

मेरा व्यक्तिगत अनुभव है कि जब परियोजनाओं है कि शुरू होता है यथोचित नीचे से ऊपर, बहुत सी बातें जिसके लिए वहाँ अपने स्वयं के -remains पर वास्तविक कक्षाएं किया जाना चाहिए था दफन या बुरा अभी भी विभिन्न वर्गों और युग्मन बढ़ जाती है के बीच विभाजन बनी हुई है। सबसे अधिक बार क्या 10 वर्गों के योग्य होगा, लेकिन केवल 4 है, यह संभावना है कि उनमें से कई में बहुउद्देश्यीय भ्रामक और बड़ी संख्या में विधियां हैं। इसे GOD और DRAGON कहें, यही BAD है।

लेकिन आप बहुत बड़े वर्गों में आते हैं जो बड़े करीने से हैं, उनके पास 30 तरीके हैं - और अभी भी बहुत साफ हैं। वे अच्छे हो सकते हैं।

Comments

सवालों के वर्ग में 23 इंटरफेस होते हैं और इनमें सभी, 113 सार्वजनिक गुण और चार विधियाँ शामिल होती हैं। उनमें से केवल कुछ ही पठनीय हैं। C # में स्वतः-कार्यान्वित गुण हैं, इसीलिए मैं msdn.microsoft.com/en-us/library/bb384054.aspx

— Jonas Elfström

Answer 6

कक्षाओं में बिल्कुल सही संख्या में इंटरफेस होना चाहिए; न आधिक न कम।

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

कुछ भाषाएं जावा के extendsकीवर्ड जैसे एक तंत्र का उपयोग करके इंटरफेस को "उपवर्गित" होने देती हैं , और जिसने भी लिखा है वह शायद यह नहीं जानता होगा। यह भी हो सकता है कि सभी 23 पर्याप्त रूप से दूर-दराज के हैं जो उन्हें एकत्रित करने से कोई मतलब नहीं था।

Comments

मुझे लगा कि यह सवाल काफी भाषा अज्ञेय था। वास्तविक कोड C # में है।

— जोनास एल्फ्रॉस्टम

मैंने कोई C # नहीं किया है, लेकिन यह इंटरफ़ेस वंशानुक्रम के समान रूप का समर्थन करता प्रतीत होता है।

— ब्लरफ्ल

हां, एक इंटरफेस अन्य इंटरफेस और "इनहेरिट" कर सकता है।

— जोनास एलफ्रॉस्टेम

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

— सुपरकैट

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

— सुपरकैट

Answer 7

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

Comments

यह C # में है और इसमें स्वतः-कार्यान्वित गुण हैं। इन 23 इंटरफेस, सभी में 113 ऐसे गुण होते हैं।

— जोनास एलफ्रॉस्टेम

Answer 8

जब एक जेनेरिक ऑब्जेक्ट का उपयोग विभिन्न वातावरणों में किया जाता है, तो इंटरफेस की संख्या अक्सर बढ़ती है। C # में IComparable, IEqualityComparer और IComparer के वेरिएंट को अलग-अलग सेटअपों में छाँटने की अनुमति मिलती है, इसलिए आप उन सभी को लागू करना समाप्त कर सकते हैं, उनमें से कुछ शायद एक से अधिक बार जेनेरिक जोरदार संस्करणों को लागू करने के साथ-साथ गैर-सामान्य संस्करणों को भी लागू कर सकते हैं। , इसके अलावा आप जेनरिक में से एक से अधिक को लागू कर सकते हैं।

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

सीरियलाइजेशन को लागू करते समय, ISerializable, IDeserializationCallback लागू हो जाता है। फिर पूर्ववत करें फिर से लागू करना: IClonable को जोड़ा जाता है। तीस कार्यक्षमता: IObservable, INotifyPropertyChanged। उपयोगकर्ताओं को स्ट्रिंग का उपयोग करके मूल्यों को संपादित करने की अनुमति देना: IConvertable ... सूची पर और पर जा सकते हैं ...

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

विशेषताओं (एनोटेशन) का उपयोग प्रतिबिंब के अधीन है। एक खामी मामूली (प्रारंभिक) प्रदर्शन हानि है। एक (अक्सर भावनात्मक) दोष यह है कि एनकैप्सुलेशन जैसे सिद्धांतों को शिथिल करने की आवश्यकता है।

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

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

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

Answer 9

"बहुत सारे" व्यक्तिपरक है: प्रोग्रामिंग शैली? प्रदर्शन? मानकों के अनुरूप? उदाहरण? सिर्फ सादा अर्थ-आराम / आत्मविश्वास?

इसलिए जब तक आपका कोड सही व्यवहार करता है और कोई स्थिरता की समस्या पेश नहीं करता है, तब तक 23 नए मानक भी हो सकते हैं। किसी दिन मैं कह सकता था, "आप 23 इंटरफेस के साथ एक उत्कृष्ट काम कर सकते हैं, देखें: जोनास एल्फ्रॉस्टेम"।

Answer 10

मैं कहूंगा कि सीमा 23 से छोटी संख्या होनी चाहिए - 5 या 7 से अधिक,
हालांकि, इसमें उन इंटरफेसों की संख्या शामिल नहीं होती है जो उन इंटरफेस को विरासत में देते हैं या आधार कक्षाओं द्वारा लागू किए गए किसी भी संख्या में इंटरफेस हैं।

(तो कुल मिलाकर, एन + विरासत में मिली इंटरफेस की कोई संख्या, जहां एन <= 7.)

यदि आपकी कक्षा बहुत अधिक इंटरफेस लागू करती है, तो यह संभवतः एक देव-वर्ग है ।