22

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

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

बिल्डर वर्ग आवश्यक था क्योंकि कंस्ट्रक्टर (जो पहली जगह में रिफैक्टिंग को प्रेरित करता है) कोड की लगभग 3 पंक्तियों तक फैला हुआ है। इसके बहुत सारे पैरामीटर हैं।

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

public void foo(Bar bar){
    //do stuff
    bar.setA(stuff);
    //do more stuff
    bar.setB(moreStuff);
}

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

public void foo(Bar bar){
    try{
        bar.setA(a);
        //enter exception-throwing stuff
        bar.setB(b);
    }catch(){}
}

यदि उस अपवाद में आग लगती है, barतो भ्रष्ट डेटा होगा, जो एक बिल्डर के साथ बचा होगा:

public Bar foo(){
        Builder builder=new Builder();
    try{
        builder.setA(a);
        //dangerous stuff;
        builder.setB(b);
        //more dangerous stuff
        builder.setC(c);
        return builder.build();
    }catch(){}
    return null;
}

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

समझौता पुराने समाधान को वापस करने का था, अर्थात् बिना किसी पैरामीटर के एक कंस्ट्रक्टर का उपयोग करें और जरूरत के अनुसार सब कुछ सेट करें। तर्क यह है कि इस समाधान KISS सिद्धांत है, जो मेरा उल्लंघन करता है, इस प्रकार था।

मैं इस कंपनी (6 महीने से कम) के लिए नया हूं और पूरी तरह से जानता हूं कि मैंने इसे खो दिया। मेरे पास प्रश्न हैं:

क्या "पुराने तरीके" के बजाय बिल्डर्स का उपयोग करने का एक और तर्क है?
क्या मैं जिस प्रस्ताव का प्रस्ताव करता हूं वह वास्तव में इसके लायक है?

लेकिन वास्तव में,

जब आप कुछ नया करने की वकालत करते हैं तो क्या आपके पास इस तरह के तर्क प्रस्तुत करने के लिए कोई सुझाव है?

design-patterns teamwork builder-pattern

— अधिक तत्पर
स्रोत

6

बिल्डर को किसी तरह मूल्यों को स्थापित करने की आवश्यकता है। तो यह मूल समस्या को हल नहीं करता है।

— एमी ब्लेंकशिप 21

3

कॉल करने से पहले (अधिक / खतरनाक / अपवाद-फेंकने वाले) सामान को किस कारण से स्थानांतरित नहीं किया जा सकता है setA?

— yatima2975

2

निर्माता मापदंडों की केवल 3 लाइनें? यह उतना बुरा नहीं है।

— pjc50

7

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

— ब्रैंडन

3

KISS एक फजी अवधारणा है, परिवर्तनीय वस्तुओं जटिलता बेहद डेवलपर्स द्वारा कम करके आंका के स्रोत हैं, वे बहु सूत्रण, डिबग और अपवादों ज्यादा अपरिवर्तनीय एक से अधिक मुश्किल से निपटने के हैं। या तो ऑब्जेक्ट वैध है या निर्माण पर एक अपवाद बनाया गया है (जो उस अपवाद को पकड़ने के लिए बेहतर जगह है?)।

— एलेसेंड्रो टेरुज़ि

46

यह सोचकर कि हमें कहीं से शुरुआत करनी है, मैंने इसे अपने लिए एक डेटा धारक वर्ग को फिर से तैयार करने के लिए लिया

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

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

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

— gbjbaanb
स्रोत

7

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

— डार्कहॉग

3

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

— ब्रैंडन

11

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

— एक्सेसर

13

@ ब्रेंडन एक कहावत है: "नरक का मार्ग अच्छे इरादों के साथ बनाया गया है"। संगति अच्छा नहीं है , यह आवश्यक है ! डेवलपर्स की एक टीम का प्रबंधन करने की कोशिश करें, जो सामूहिक रूप से 20 अनुप्रयोगों का प्रबंधन करते हैं, जिनमें से प्रत्येक को एक अलग शैली और / या वास्तुकला में लिखा गया है क्योंकि वरीयताएँ, वर्तमान तकनीक, रुझान, आदि ने तय किया था कि उस समय क्या सबसे अच्छा था। टीम को इस बात के लिए सहमत होना कि कुछ परिवर्तन होना चाहिए नए व्यक्ति को स्वीकार किए जाने के बीच अंतर हो सकता है क्योंकि उन्होंने एक लंबे समय तक चलने वाली समस्या को ठीक किया, और जो आपने सोचा था उसके साथ घुड़सवार होने के लिए निकाल दिया गया।

— DrewJordan

3

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

— डंक

21

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

जैसा कि वर्णन किया गया है, मैं नहीं देखता कि क्या कोड को बसने की आवश्यकता है । मैं शायद उपयोग-मामले के बारे में पर्याप्त नहीं जानता, लेकिन तब तक क्यों नहीं प्रतीक्षा करता जब तक कि ऑब्जेक्ट को तत्काल करने से पहले सभी मापदंडों को नहीं जाना जाता?

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

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

सामान्य टिप्स

पुराना = बुरा, नया = अच्छा, मेरा तरीका, आपका तरीका ... इस तरह की चर्चा रचनात्मक नहीं है।

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

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

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

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

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

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

जब आप अपने तर्क प्रस्तुत करते हैं, तो आपको कुछ "पवित्रता" चेक करना होगा: क्या आप विचार या अपने आप को बेचने की कोशिश कर रहे हैं? अगर किसी और ने इसे टीम के सामने पेश किया तो क्या होगा? क्या आप उनके तर्क में कुछ खामियां पाएंगे? क्या आप कुछ सामान्य सर्वोत्तम अभ्यास को लागू करने की कोशिश कर रहे हैं या आपने अपने कोड की बारीकियों को ध्यान में रखा है?

उसके बाद, आप निश्चित रूप से प्रकट नहीं होते हैं, जैसे कि आप अपनी टीम की पिछली "गलतियों" को ठीक करने का प्रयास कर रहे हैं। यह दिखाने में मदद करता है कि आप अपने विचार नहीं हैं, लेकिन उचित प्रतिक्रिया ले सकते हैं। जितना अधिक आप यह करेंगे आपके सुझावों का पालन करने का अवसर होगा।

— कोर निपात
स्रोत

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

— रथ

@rath क्या कोई नया कोडबेस विकसित नहीं किया जा रहा है?

— biziclop

@biziclop पुराने कोडबेस में नए मॉड्यूल लगाए जा रहे हैं। मैंने हाल ही में एक पर काम किया। खुशी के दिन।

— रथ

5

@ रथ को शायद आपको एक व्यक्तिगत परियोजना की आवश्यकता है जिसे आप अपने समय पर काम कर सकते हैं जहां आप अपने स्वयं के विकास को आगे बढ़ा सकते हैं? मैं आपके "बिल्डर" पैटर्न तर्क से आश्वस्त नहीं हूं; आपके द्वारा दी गई जानकारी के आधार पर गेटर्स / सेटर पूरी तरह से ठीक समाधान प्रतीत होते हैं। याद रखें कि आप अपने नियोक्ता और अपनी टीम के प्रति जवाबदेह हैं; आपकी प्राथमिकता यह सुनिश्चित कर रही है कि आप जो भी काम करते हैं, उससे उन लोगों को फायदा हो, जिनके प्रति आप जवाबदेह हैं।

— बेन कॉटरेल

@ ठीक है, भले ही आप "पुराने / नए" कोड में नहीं हैं, क्या मायने रखता है कि यह कैसे प्राप्त अंत तक माना जाता है, खासकर यदि उनके पास आपके मुकाबले अधिक निर्णय शक्ति है। ऐसा लगता है कि जैसे आप अपने हित के लिए बदलाव लाना चाहते हैं न कि आपके द्वारा विकसित उत्पाद के लिए। यदि कंपनी में सभी लोग अभ्यास को भयानक पाते हैं, तो यह अंततः बदल जाएगा, लेकिन ऐसा नहीं लगता कि यह प्राथमिकता है।

— coredump

17

मैं अपनी टीम में बिल्डर पैटर्न के उपयोग को कैसे बढ़ावा दे सकता हूं?

तुम नहीं।

यदि आपके निर्माता के मापदंडों की 3 लाइनें हैं, तो यह बहुत बड़ा है और बहुत जटिल है। कोई डिज़ाइन पैटर्न ठीक नहीं करेगा।

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

— Telastyn
स्रोत

यह एक बड़ा डेटा धारक है Stringअन्य और आदिम है। कहीं भी कोई तर्क नहीं है, nullएस आदि के लिए भी जाँच नहीं है, इसलिए यह सिर्फ सरासर आकार है, प्रति जटिलता नहीं। मैंने सोचा कि कुछ builder.addA(a).addB(b); /*...*/ return builder.addC(c).build();करना आंखों पर बहुत आसान होगा।

— राठ

8

@ रथ: यह स्ट्रिंग्स और अन्य आदिमियों का एक बड़ा डेटा धारक है। => फिर आपको अन्य समस्याएं हैं, आशा है कि ई-मेल फ़ील्ड आकस्मिक होने पर किसी को परवाह नहीं है, लड़के के पोस्ट पते के साथ ...

— मैथ्यू एम।

@MatthieuM। एक बार में मुझे एक समस्या

— लगती है

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

— डंक

1

मैं रास्ते से अधिक मापदंडों के साथ कई निर्माताओं soooooo है। आईओसी पैटर्न में आवश्यक। इस उत्तर में खराब सामान्यीकरण।

— djechlin

16

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

उस का उलटा।

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

इसे लगातार करें और आपको कम संघर्ष पैदा करना चाहिए, और अपने विचारों को दूसरों के द्वारा अपनाया जाना चाहिए। हम सभी इस भ्रम से ग्रस्त हैं कि सही तार्किक तर्क दूसरों को वाह करेंगे और दिन जीतेंगे। और अगर यह उस तरह से काम नहीं करता है, तो हमें लगता है कि यह करना चाहिए ।

लेकिन यह वास्तविकता के साथ सीधे संघर्ष में है। अधिकांश तर्क खो जाते हैं पहले तार्किक बिंदु बनने से पहले। यहां तक कि कथित रूप से तार्किक लोगों के बीच, मनोविज्ञान ट्रम्प का कारण बनता है। लोगों को समझाने के बारे में पिछले मनोवैज्ञानिक बाधाओं को ठीक से सुना जा रहा है, और सही तर्क होने के बारे में नहीं है।

— btilly
स्रोत

2

Frame your thoughts as suggestions and ideas. Get THEM to talk through THEIR ideas before asking questions to make them think about yours

फिर भी उस गैर के लिए +1

— रथ

2

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

— इकेर

2

@ रथ: कोई सही या गलत नहीं है। बस व्यापार बंद। और अधिक से अधिक बार व्यापार बंद अकेले कोड से अधिक शामिल नहीं है।

— मार्जन वेनमा

1

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

— btilly

2

एक एकल प्रोग्रामिंग "सर्वश्रेष्ठ अभ्यास" नहीं है जो मुझे पता है कि इसके अपवाद नहीं हैं जहां यह सबसे अच्छा नहीं है। कभी-कभी उन अपवादों को खोजना मुश्किल होता है, लेकिन वे हमेशा मौजूद रहते हैं।

— btilly

11

क्या "पुराने तरीके" के बजाय बिल्डर्स का उपयोग करने का एक और तर्क है?

"जब आपके पास एक नया हथौड़ा होगा, तो सब कुछ एक नाखून की तरह दिखाई देगा।" - यह मैंने तब सोचा जब मैंने आपका प्रश्न पढ़ा।

अगर मैं आपका सहकर्मी होता, तो मैं आपसे पूछता कि "क्यों नहीं, निर्माणकर्ता में पूरे ऑब्जेक्ट को इनिशियलाइज़ किया जाए?" यही कारण है कि यह सब के बाद यह कार्यक्षमता है। बिल्डर (या किसी अन्य डिज़ाइन) पैटर्न का उपयोग क्यों करें?

क्या मैं जिस प्रस्ताव का प्रस्ताव करता हूं वह वास्तव में इसके लायक है?

उस छोटे कोड स्निपेट से बताना मुश्किल है। शायद यह है - आप और आपके सहकर्मियों को इसका मूल्यांकन करने की आवश्यकता है।

जब आप कुछ नया करने की वकालत करते हैं तो क्या आपके पास इस तरह के तर्क प्रस्तुत करने के लिए कोई सुझाव है?

हां, चर्चा करने से पहले विषय के बारे में अधिक जानें। चर्चा में प्रवेश करने से पहले अपने आप को अच्छे तर्क और तर्क के साथ समझें।

— BЈовић
स्रोत

7

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

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

वास्तविक प्रश्न के लिए

अपरिवर्तनीय वस्तुओं का उपयोग क्यों करें? क्योंकि आप जानते हैं कि आप किसके साथ काम कर रहे हैं।

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

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

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

Tl, डॉ

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

— सुपर हीरो
स्रोत

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

— डंक

1

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

— सुपरहीरो

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

— सुपरहीरो

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

— डंक

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

— सुपरहीरो

2

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

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

// business objects

interface CharRange {
   public char getCharacter();
   public int getFrom();
   public int getTo();
}

class MultiCharRange implements CharRange {
   final char ch;
   final int from;
   final int to;

   public char getCharacter() { return ch; }
   public int getFrom() { return from; }
   public int getTo() { return to; }
}

class SingleCharRange implements CharRange {
   final char ch;
   final int position;

   public char getCharacter() { return ch; }
   public int getFrom() { return position; }
   public int getTo() { return position; }
}

// builders

class Builder1 {
   public Builder2 character(char ch) {
      return new Builder2(ch);
   }
}

class Builder2 {
   final char ch;
   int from;
   int to;

   public Builder2 range(int from, int to) {
      if (from > to) throw new IllegalArgumentException("from > to");
      this.from = from;
      this.to = to;
      return this;
   }

   public Builder2 zeroStartRange(int to) {
      this.from = 0;
      this.to = to;
      return this;
   }

   public CharRange build() {
      if (from == to)
         return new SingleCharRange(ch,from);
      else 
         return new MultiCharRange(ch,from,to);
   }
}

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

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

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

आपके सहकर्मियों ने बस यह तय किया कि व्यापार बंद फायदेमंद नहीं होगा। आपको सार सिद्धांतों का सहारा लिए बिना, खुले तौर पर और ईमानदारी से, अधिमानतः कारणों पर चर्चा करनी चाहिए, लेकिन इस समाधान के व्यावहारिक निहितार्थ या उस पर ध्यान केंद्रित करना चाहिए।

— biziclop
स्रोत

1

किसी ऑब्जेक्ट के निर्माण को एक प्रक्रिया में बदलकर, आप जटिल तार्किक बाधाओं को लागू कर सकते हैं। BAM। और यह सब इस जटिलता के बारे में बताता है जब इसे छोटे, असतत, सरल चरणों में व्यवस्थित किया जाता है ।

— राडारबॉब

2

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

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

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

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

— नील बर्नवेल
स्रोत

यह निश्चित रूप से समिति द्वारा डिज़ाइन नहीं किया गया है, जो इस कारण का हिस्सा है कि कोड इतना खराब क्यों है। बहुत अच्छी बात है कि मुझे लगता है। यह है एक डीटीओ लेकिन मैं इसे तोड़ने नहीं होगा ऊपर टुकड़ों में; अगर कोडबेस खराब है, तो DB ज्यादा खराब है। अंतिम पैराग्राफ के लिए +1 (प्राथमिक रूप से)।

— रथ