इंटरफेस के भविष्य के उपयोग के लिए प्रोग्रामिंग

42

मेरे बगल में एक सहकर्मी बैठा है जिसने इस तरह का इंटरफ़ेस तैयार किया है:

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

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

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

अब, मेरा प्रश्न यह है कि क्या कोई ऐसे स्रोत हैं जो "सम्मानित" कोडिंग गुरुओं जैसे विषय को संभाल रहे हैं जिन्हें हम उससे जोड़ सकते हैं?

java object-oriented-design interfaces

— sveri
स्रोत

29

"भविष्यवाणी बहुत मुश्किल है, खासकर भविष्य के बारे में।"

— जोर्ग डब्ल्यू मित्तग

10

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

— डोभाल

5

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

— Rémi

3

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

— बोरिस स्पाइडर

1

@ डोभाल को मैं जावा के बारे में नहीं जानता, लेकिन .NET में आप कभी-कभी ऐसी चीजों को देखेंगे, IQueryableजो डीएएल के बाहर कोड करने के लिए (केवल कुछ भावों को ले सकती हैं)

— बेन आरोनसन

62

उसे YAGNI के बारे में जानने के लिए आमंत्रित करें । विकिपीडिया पृष्ठ का औचित्य भाग यहाँ विशेष रूप से दिलचस्प हो सकता है:

जो लोग YAGNI दृष्टिकोण की वकालत करते हैं, उनके अनुसार कोड लिखने का प्रलोभन जो इस समय आवश्यक नहीं है, लेकिन भविष्य में हो सकता है, निम्नलिखित नुकसान हैं:

खर्च किए गए समय को आवश्यक कार्यक्षमता को जोड़ने, परीक्षण या सुधारने से लिया जाता है।

नई सुविधाओं को डीबग, प्रलेखित और समर्थित होना चाहिए।

भविष्य में क्या किया जा सकता है, इस पर कोई भी नई सुविधा अड़चन डालती है, इसलिए एक अनावश्यक विशेषता भविष्य में जोड़े जाने से आवश्यक सुविधाओं को रोक सकती है।

जब तक सुविधा वास्तव में आवश्यक है, तब तक यह पूरी तरह से परिभाषित करना मुश्किल है कि इसे क्या करना चाहिए और इसका परीक्षण करना चाहिए। यदि नई सुविधा को ठीक से परिभाषित और परीक्षण नहीं किया गया है, तो यह सही ढंग से काम नहीं कर सकती है, भले ही अंततः इसकी आवश्यकता हो।

यह कोड ब्लोट की ओर जाता है; सॉफ्टवेयर बड़ा और अधिक जटिल हो जाता है।

जब तक विनिर्देशों और कुछ प्रकार के संशोधन नियंत्रण नहीं होते हैं, तब तक इस सुविधा को प्रोग्रामर को नहीं पता हो सकता है जो इसका उपयोग कर सकते हैं।

नई सुविधा जोड़ना अन्य नई सुविधाओं का सुझाव दे सकता है। यदि इन नई सुविधाओं को भी लागू किया जाता है, तो इसका परिणाम फीचर रेंगना की ओर स्नोबॉल प्रभाव हो सकता है।

अन्य संभावित तर्क:

"सॉफ्टवेयर के एक टुकड़े की जीवन भर की लागत का 80% रखरखाव में चला जाता है" । केवल समय में कोड लिखने से रखरखाव की लागत कम हो जाती है: किसी को कम कोड बनाए रखना पड़ता है, और वास्तव में आवश्यक कोड पर ध्यान केंद्रित कर सकता है।
सोर्स कोड एक बार लिखा जाता है, लेकिन दर्जनों बार पढ़ा जाता है। एक अतिरिक्त तर्क, जिसका कहीं भी उपयोग नहीं किया जाता है, इससे समय बर्बाद होता है और यह समझ में आता है कि ऐसा तर्क क्यों है जिसकी आवश्यकता नहीं है। यह देखते हुए कि यह एक ऐसा इंटरफ़ेस है जिसमें कई संभावित कार्यान्वयन केवल चीजों को और अधिक कठिन बनाते हैं।
स्रोत कोड से स्व-दस्तावेजीकरण होने की उम्मीद है। वास्तविक हस्ताक्षर भ्रामक है, क्योंकि एक पाठक सोचता है कि endपरिणाम या विधि के निष्पादन को प्रभावित करता है।
इस इंटरफ़ेस के ठोस कार्यान्वयन लिखने वाले व्यक्ति यह नहीं समझ सकते हैं कि अंतिम तर्क का उपयोग नहीं किया जाना चाहिए, जो विभिन्न दृष्टिकोणों को जन्म देगा:
1. मुझे इसकी आवश्यकता नहीं है end, इसलिए मैं इसके मूल्य की उपेक्षा करूँगा,
2. मुझे ज़रूरत नहीं है end, इसलिए मैं एक अपवाद फेंक दूंगा अगर यह नहीं है null,
3. मुझे जरूरत नहीं है end, लेकिन किसी तरह इसका इस्तेमाल करने की कोशिश करूंगा,
4. मैं बहुत सारे कोड लिखूंगा जिनका बाद में उपयोग किया जा सकता है जब endआवश्यकता होगी।

लेकिन ध्यान रखें कि आपका सहकर्मी सही हो सकता है।

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

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

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

— आर्सेनी मूरज़ेंको
स्रोत

4

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

— जीरो वेनवेल

3

@JeroenVannevel: निश्चित रूप से, लेकिन यह बहुत ही सट्टा है। मेरे अनुभव से, मुझे लगता है कि निश्चित रूप से लागू की जाने वाली अधिकांश विशेषताएं या तो रद्द कर दी गईं या हमेशा के लिए देरी हो गई। इसमें ऐसी विशेषताएं शामिल हैं जिन्हें मूल रूप से हितधारकों द्वारा बहुत महत्वपूर्ण रूप से उजागर किया गया था।

— आर्सेनी मूरज़ेंको

26

लेकिन वह इस बात पर जोर देता रहता है कि अगर हमें कुछ समय बाद "अंत" तिथि के उपयोग को लागू करना है, तो बहुत सारे काम करने पड़ेंगे और फिर सभी कोड को अनुकूलित करना होगा।

(कुछ समय बाद)

public class EventGetter implements IEventGetter {

    private static final Date IMPLIED_END_DATE_ASOF_20140711 = new Date(Long.MAX_VALUE); // ???

    @Override
    public List<FooType> getFooList(String fooName, Date start) throws Exception {
        return getFooList(fooName, start, IMPLIED_END_DATE_ASOF_20140711);
    }

    @Override
    public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception {
        // Final implementation goes here
    }
}

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

— hjk
स्रोत

6

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

— कीवली

1

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

— hjk

18

[हैं] "सम्मानित" कोडिंग गुरु जो हम उसे [उसे मनाने के लिए] से जोड़ सकते हैं?

प्राधिकरण के लिए अपील विशेष रूप से आश्वस्त नहीं हैं; एक तर्क प्रस्तुत करने के लिए बेहतर है जो किसी भी मामले में मान्य नहीं है जिसने यह कहा है।

यहां एक रिडक्टिओ विज्ञापन एब्सर्डम दिया गया है, जिसे समझाना या प्रदर्शित करना चाहिए कि आपका सहकर्मी संवेदनशीलता की परवाह किए बिना "सही" होने पर अड़ा हुआ है:

आपको वास्तव में क्या चाहिए

getFooList(String fooName, Date start, Date end, Date middle, 
           Date one_third, JulianDate start, JulianDate end,
           KlingonDate start, KlingonDate end)

आप कभी नहीं जानते कि कब आपको क्लिंगन के लिए अंतर्राष्ट्रीयकरण करना होगा, इसलिए आप अब बेहतर तरीके से इसका ध्यान रखेंगे क्योंकि इसके लिए बहुत अधिक मेहनत करनी पड़ेगी और क्लिंगन को अपने धैर्य के लिए नहीं जाना जाता है।

— एमएसडब्ल्यू
स्रोत

22

You never know when you'll have to internationalize for Klingon। इसलिए आपको बस एक पास करना चाहिए Calendar, और ग्राहक कोड को यह तय करने देना चाहिए कि क्या वह एक भेजना चाहता है GregorianCalendarया KlingonCalendar(मैं शर्त लगा सकता हूं कि पहले से ही कुछ किया है)। ओह। :

— -पी

3

के बारे में StarDate sdStartऔर क्या StarDate sdEnd? हम सब के बाद फेडरेशन के बारे में नहीं भूल सकते ...

— WernerCD

उन सभी को या तो स्पष्ट रूप से उप-वर्ग या परिवर्तनीय हैं Date!

— डार्कहॉग

यदि केवल यह इतना आसान था ।

— msw

@msw, मुझे यकीन नहीं है कि वह "अथॉरिटी से अपील" करने के लिए कह रहा था जब उसने "सम्मानित कोडिंग गुरु" के लिंक के लिए कहा था। जैसा कि आप कहते हैं, उसे "एक तर्क की आवश्यकता है जो किसी भी मामले में मान्य नहीं है जो उसने कहा है"। "गुरु" -प्रत्येक लोग बहुत कुछ जानते हैं। इसके अलावा आप भूल गए HebrewDate startऔर HebrewDate end।

— trysis

12

एक सॉफ्टवेयर इंजीनियरिंग के नजरिए से, मेरा मानना है कि इस तरह की समस्याओं का उचित समाधान बिल्डर पैटर्न में है। यह निश्चित रूप से आपके सहयोगी http://en.wikipedia.org/wiki/Builder_pattern के लिए 'गुरु' लेखकों की एक कड़ी है ।

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

आपका उदाहरण बन जाएगा:

public interface IEventGetter {
    public List<FooType> getFooList(ISearchFooRequest req) {
        throws Exception;
    ....
    }
}

public interface ISearchFooRequest {
        public String getName();
        public Date getStart();
        public Date getEnd();
        public int getOffset();
        ...
    }
}

public class SearchFooRequest implements ISearchFooRequest {

    public static SearchFooRequest buildDefaultRequest(String name, Date start) {
        ...
    }

    public String getName() {...}
    public Date getStart() {...}
    ...
    public void setEnd(Date end) {...}
    public void setOffset(int offset) {...}
    ...
}

— InformedA
स्रोत

3

यह एक अच्छा सामान्य दृष्टिकोण है, लेकिन इस मामले में समस्या को केवल धक्का देना प्रतीत होता IEventGetterहै ISearchFootRequest। मैं इसके बजाय public IFooFilterसदस्य के साथ ऐसा कुछ सुझाता हूं, public bool include(FooType item)जो आइटम को शामिल करता है या नहीं। तब अलग-अलग इंटरफ़ेस कार्यान्वयन यह तय कर सकते हैं कि वे उस फ़िल्टरिंग को कैसे करेंगे

— बेन आरोनसन

@ बान आरोनसन मैं सिर्फ यह दिखाने के लिए कोड का अनुरोध करता हूं कि अनुरोध पैरामीटर ऑब्जेक्ट कैसे बनाया जाता है

— InformedA

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

— हारून ने

7

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

public interface IEventGetter {

    public List<FooType> getFooList(String fooName, Date start)
         throws Exception;
    ....

}

public interface IBoundedEventGetter extends IEventGetter {

    public List<FooType> getFooList(String fooName, Date start, Date end)
        throws Exception;
    ....

}

— ToddR
स्रोत

मौजूदा (और शायद पहले से परीक्षण / शिप किए गए) इंटरफ़ेस को नहीं बदलने के लिए +1।

— सेबेस्टियन गोडलेट

4

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

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

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

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

— कार्ल बेवफेल्ड
स्रोत

2

इस प्रश्न का उत्तर देने के लिए पर्याप्त जानकारी नहीं है। यह getFooListवास्तव में क्या करता है, और यह कैसे करता है पर निर्भर करता है।

यहां एक विधि का एक स्पष्ट उदाहरण है जो एक अतिरिक्त पैरामीटर का समर्थन करना चाहिए, जिसका उपयोग किया गया है या नहीं।

void CapitalizeSubstring (String capitalize_me, int start_index);

एक विधि को लागू करना जो एक संग्रह पर संचालित होता है जहां आप शुरुआत को निर्दिष्ट कर सकते हैं लेकिन संग्रह का अंत अक्सर मूर्खतापूर्ण नहीं होता है।

आपको वास्तव में समस्या को स्वयं देखना होगा और पूछना होगा कि क्या पैरामीटर पूरे इंटरफ़ेस के संदर्भ में निरर्थक है, और वास्तव में अतिरिक्त पैरामीटर कितना बोझ डालता है।

— QuestionC
स्रोत

1

मुझे डर है कि आपके सहकर्मी के पास वास्तव में एक बहुत ही वैध बिंदु हो सकता है। यद्यपि उसका समाधान वास्तव में सर्वश्रेष्ठ नहीं है।

उनके प्रस्तावित इंटरफ़ेस से यह स्पष्ट है कि

public List<FooType> getFooList(String fooName, Date start, Date end) throws Exception;

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

तो एक बेहतर इंटरफ़ेस होगा:

public List<FooType> getFooList(String fooName, Interval interval) throws Exception;

यदि आप एक स्थिर कारखाने विधि के साथ अंतराल की आपूर्ति करते हैं:

public static Interval startingAt(Date start) { return new Interval(start, null); }

तब ग्राहकों को भी अंतिम समय निर्दिष्ट करने की आवश्यकता महसूस नहीं होगी।

उसी समय आपका इंटरफ़ेस अधिक सही ढंग से बताता है कि यह क्या करता है, क्योंकि getFooList(String, Date)यह संवाद नहीं करता है कि यह अंतराल से संबंधित है।

ध्यान दें कि मेरा सुझाव इस पद्धति का अनुसरण करता है कि वर्तमान में क्या करना है, न कि भविष्य में क्या करना चाहिए या क्या करना चाहिए, और जैसे कि YAGNI सिद्धांत (जो वास्तव में बहुत वैध है) यहां लागू नहीं होता है।

— बोमोर
स्रोत

0

अप्रयुक्त पैरामीटर जोड़ना भ्रामक है। लोग इस पद्धति को मान सकते हैं कि यह सुविधा काम करेगी।

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

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

— usr
स्रोत