उपयोगिता वर्ग बुराई है? [बन्द है]

Question

मैंने यह धागा देखा

यदि "उपयोगिताएँ" वर्ग बुराई है, तो मैं अपना सामान्य कोड कहाँ रखूँ?

और सोचा कि उपयोगिता वर्ग बुराई क्यों हैं?

आइए बताते हैं कि मेरे पास एक डोमेन मॉडल है जो दर्जनों कक्षाओं में गहरा है। मुझे xml-ify उदाहरणों में सक्षम होना चाहिए। क्या मैं माता-पिता पर एक toxml विधि बना सकता हूं? क्या मैं MyDomainXmlUtility.toXml हेल्पर क्लास कर सकता हूं? यह एक ऐसा मामला है जहां व्यवसाय को पूरे डोमेन मॉडल की आवश्यकता होती है - क्या यह वास्तव में एक उदाहरण विधि के रूप में है? क्या होगा अगर आवेदन की xml कार्यक्षमता पर सहायक विधियों का एक गुच्छा हो?

Comments

"बुराई" शब्द का अवमूल्यन बुराई है!

— मैथ्यू लॉक

@matthew मैंने उस पद की शर्तों को संरक्षित किया है, जिस पर मेरा प्रश्न आधारित है ...;)

— hvgotcodes

उपयोगिता वर्ग उन्हीं कारणों के लिए एक बुरा विचार है जो एकल हैं।

— कर्टनडॉग

क्या एक toXML विधि है पर बहस एक अमीर बनाम एनीमिक डोमेन मॉडल पर केंद्रित है। codeflow.blogspot.com/2007/05/anemic-vs-rich-domain-models.html

— जेम्स पी।

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

— सबक्लासिंग का

Answer 1

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

हालांकि, ऐसे समय होते हैं जब आप उपयोगिता वर्गों का उपयोग कई तरीकों को एक साथ समूह में करने के लिए कर सकते हैं - एक उदाहरण वह java.util.Collectionsवर्ग जो कई उपयोगिताओं को प्रदान करता है जो किसी भी जावा संग्रह पर उपयोग किए जा सकते हैं। ये एक विशेष प्रकार के संग्रह के लिए विशिष्ट नहीं हैं, बल्कि इसके बजाय किसी भी संग्रह पर उपयोग किए जाने वाले एल्गोरिदम को लागू कर सकते हैं।

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

Comments

इस लेख के साथ अच्छी तरह से पढ़ने के लिए उपयोगिता / सहायक वर्ग के खिलाफ SOLID oo सिद्धांत के खिलाफ अच्छी तरह से पठनीयता

— ।articles

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

— अनसलैंडर मोनिका

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

— जो तो

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

— जो तो

यूटिल और हेल्पर कक्षाएं इस तरह की बाधाओं की एक दुर्भाग्यपूर्ण कलाकृति हैं, और जो लोग ओओपी को नहीं समझते हैं या समस्या को नहीं समझते हैं उन्होंने प्रक्रियात्मक कोड लिखना जारी रखा है।

— बिल्वोविच

Answer 2

मुझे लगता है कि आम सहमति यह है कि उपयोगिता वर्ग प्रति से बुराई नहीं है । आपको बस उन्हें विवेकपूर्ण तरीके से उपयोग करने की आवश्यकता है:

• सामान्य और पुन: प्रयोज्य होने के लिए स्थिर उपयोगिता विधियों को डिज़ाइन करें। सुनिश्चित करें कि वे स्टेटलेस हैं; यानी कोई स्थिर चर नहीं।

• यदि आपके पास बहुत से उपयोगिता विधियां हैं, तो उन्हें कक्षाओं में इस तरह से विभाजित करें जिससे डेवलपर्स के लिए उन्हें ढूंढना आसान हो जाए।

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

• जावा 8 के लिए, इंटरफ़ेस में "डिफ़ॉल्ट तरीके" उपयोगिता वर्गों की तुलना में बेहतर विकल्प हो सकते हैं। ( उदाहरण के लिए जावा 8 में सार वर्ग बनाम डिफ़ॉल्ट विधियों के साथ इंटरफेस देखें ।)

---

इस प्रश्न को देखने का दूसरा तरीका यह है कि उद्धृत प्रश्न में, "यदि उपयोगिता वर्ग" दुष्ट "हैं" तो एक स्ट्रोमैन तर्क है। यह मेरे जैसे पूछ रहा है:

"अगर सूअर उड़ सकते हैं, तो क्या मुझे एक छाता ले जाना चाहिए?"।

उपरोक्त प्रश्न में, मैं वास्तव में यह नहीं कह रहा हूं कि सूअर उड़ सकते हैं ... या यह कि मैं इस प्रस्ताव से सहमत हूं कि वे उड़ सकते हैं।

विशिष्ट "xyz बुराई है" बयान बयानबाजी के उपकरण हैं जो एक चरम दृष्टिकोण प्रस्तुत करके आपको सोचने के लिए प्रेरित करते हैं। वे शायद ही कभी (यदि कभी भी) शाब्दिक तथ्य के बयान के रूप में इरादा कर रहे हैं।

Answer 3

उपयोगिता वर्ग समस्याग्रस्त हैं क्योंकि वे उन डेटा के साथ समूह की जिम्मेदारियों को विफल करते हैं जो उनका समर्थन करते हैं।

वे हालांकि बेहद उपयोगी हैं और मैं उन्हें हर समय या तो स्थायी संरचनाओं के रूप में या अधिक गहन रिफ्लेक्टर के दौरान पत्थरों के रूप में निर्माण करता हूं।

एक से स्वच्छ कोड परिप्रेक्ष्य उपयोगिता वर्गों एकल उत्तरदायित्व और खुली बंद सिद्धांत का उल्लंघन। उनके पास बदलने के लिए बहुत सारे कारण हैं और डिजाइन के हिसाब से नहीं हैं। वे वास्तव में केवल मध्यवर्ती cruft के रूप में मौजूद होना चाहिए।

Comments

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

— अनसलैंडर मोनिका

मुझे कुंद होने का अफसोस है, लेकिन "स्टेटलेस स्टेटिक मेथड्स [...] एक OOP सिस्टम में ऑडबॉल" [...] दार्शनिक समस्या "बेहद भ्रामक है। यदि आप राज्य से बच सकते हैं तो यह बहुत अच्छा है क्योंकि इससे सही कोड लिखना आसान हो जाता है। यह तब होता है जब मुझे लिखना होता है x.equals(y)क्योंकि 1) तथ्य यह है कि यह वास्तव में किसी भी स्थिति को संशोधित नहीं करना चाहिए जो भी व्यक्त नहीं किया गया है (और मैं इसे लागू नहीं करने पर भरोसा नहीं कर सकता) 2) मुझे कभी भी x"में डालने का इरादा नहीं था " इष्ट "या" y3 की तुलना में "स्थिति पर काम किया ) मैं" पहचान "पर विचार नहीं करना चाहता xया yकेवल उनके मूल्यों में दिलचस्पी रखता हूं।

— जॉय सो

वास्तविक दुनिया में वास्तव में सबसे अधिक कार्यक्षमता सबसे स्थिर, स्टेटलेस, गणितीय कार्यों के रूप में व्यक्त की जाती है। क्या Math.PI एक वस्तु है जिसे उत्परिवर्तित किया जाना चाहिए? क्या मुझे वास्तव में एक AbstractSineCalculator को तुरंत लागू करना है जो IAbstractRealOperation को लागू करता है बस एक नंबर की साइन प्राप्त करने के लिए?

— जो सो

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

— Alain O'Dea

@ AlainO'Dea: मुझे एहसास है कि स्टेटलेस कार्यक्षमता के खिलाफ खड़े होने के रूप में मुझे आपकी टिप्पणी गलत लगी। मैं अपने स्वर के लिए माफी माँगता हूँ - मैं वर्तमान में अपनी पहली जावा परियोजना में शामिल हूँ (क्योंकि मैंने अपने 10 वर्षों के प्रोग्रामिंग के अधिकांश भाग के लिए ओओपी से परहेज किया था) और अस्पष्ट स्थिति और अस्पष्ट स्थिति की परतों के नीचे दफन हूँ। और मुझे बस कुछ ताजा हवा की आवश्यकता है :-)।

— जॉय सो

Answer 4

मुझे लगता है कि जब यह बुराई बनने लगती है

1) यह बहुत बड़ा हो जाता है (बस उन्हें इस मामले में सार्थक श्रेणियों में समूहित करें)।
2) वे विधियाँ जो स्थिर विधियाँ नहीं होनी चाहिए, मौजूद हैं

लेकिन जब तक इन शर्तों को पूरा नहीं किया जाता है, मुझे लगता है कि वे बहुत उपयोगी हैं।

Comments

"वे विधियाँ जो स्थिर विधियाँ नहीं होनी चाहिए, मौजूद हैं।" यह कैसे हो सकता है?

— कोरे तुगे

@KorayTugay स्थैतिक Widget.compareTo(Widget widget)बनाम गैर-स्थैतिक पर विचार करें WidgetUtils.compare(Widget widgetOne, Widget widgetTwo)। तुलना एक ऐसी चीज का उदाहरण है जिसे वैधानिक रूप से नहीं किया जाना चाहिए।

— ndm13

Answer 5

अंगूठे का नियम

आप इस समस्या को दो दृष्टिकोणों से देख सकते हैं:

• संपूर्ण *Util तरीके अक्सर खराब कोड डिजाइन या आलसी नामकरण सम्मेलन का सुझाव होते हैं।
• यह पुन: प्रयोज्य क्रॉस-डोमेन स्टेटलेस फ़ंक्शंस के लिए वैध डिज़ाइन समाधान है। कृपया ध्यान दें कि लगभग सभी सामान्य समस्याओं के लिए मौजूदा समाधान हैं।

---

उदाहरण 1. utilकक्षाओं / मॉड्यूल का सही उपयोग । बाहरी पुस्तकालय उदाहरण

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

---

उदाहरण 2. utilकक्षाओं / मॉड्यूल का सही उपयोग । utilटीम के अन्य सदस्यों के लिए बिना किसी बहाने के अपना लेखन करना

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

यहाँ छोटा, लेकिन महत्वपूर्ण विवरण है। कक्षा / मॉड्यूल लिखा है आप नहीं बुलाया जाता है HolidayUtil, लेकिन PolishHolidayCalculator। कार्यात्मक रूप से यह एक utilवर्ग है, लेकिन हम सामान्य शब्द से बचने में कामयाब रहे हैं।

Comments

एक yEd प्रशंसक मैं देख रहा हूँ;) कमाल का ऐप।

— श्रीधर सरनोबत

Answer 6

उपयोगिता वर्ग खराब हैं क्योंकि उनका मतलब है कि आप वर्ग के लिए एक बेहतर नाम सोचने के लिए बहुत आलसी थे :)

कहा जा रहा है, मैं आलसी हूं। कभी-कभी आपको बस काम पूरा करने की ज़रूरत होती है और आपके दिमाग को एक खालीपन लगता है .. यही कारण है कि "यूटिलिटी" कक्षाएं शुरू होती हैं।

Answer 7

अब इस प्रश्न को देखते हुए, मैं कहूंगा कि C # विस्तार विधियाँ उपयोगिता वर्गों की आवश्यकता को पूरी तरह से नष्ट कर देती हैं। लेकिन सभी भाषाओं में ऐसा कोई जीनियस निर्माण नहीं है।

आपके पास जावास्क्रिप्ट भी है, जहाँ आप मौजूदा ऑब्जेक्ट पर एक नया फ़ंक्शन जोड़ सकते हैं।

लेकिन मुझे यकीन नहीं है कि वास्तव में सी ++ जैसी पुरानी भाषा में इस समस्या को हल करने का एक सुंदर तरीका है ...

अच्छा OO कोड लिखना कठिन है, और लिखने के बाद से खोजना मुश्किल है OO लिखने के लिए बहुत अधिक समय / ज्ञान की आवश्यकता होती है।

और जब आप एक बजट पर होते हैं, तो आपका बॉस हमेशा यह देखकर खुश नहीं होता है कि आपने पूरा दिन कक्षाओं का एक समूह लिखने में बिताया है ...

Answer 8

मैं पूरी तरह से सहमत नहीं हूं कि उपयोगिता वर्ग बुराई हैं।

हालांकि एक उपयोगिता वर्ग कुछ तरीकों से OO रियासतों का उल्लंघन कर सकता है, वे हमेशा खराब नहीं होते हैं।

उदाहरण के लिए, कल्पना करें कि आप एक ऐसा फ़ंक्शन चाहते हैं जो सभी सबस्ट्रिंग के एक स्ट्रिंग को साफ कर देगा x ।

stl c ++ (अभी तक) इसका सीधे समर्थन नहीं करता है।

आप एक बहुरूपिक विस्तार बना सकते हैं std::string ।

लेकिन समस्या यह है, क्या आप वास्तव में चाहते हैं कि आप अपनी परियोजना में उपयोग किए जाने वाले स्ट्रिंग को अपने विस्तारित स्ट्रिंग वर्ग के रूप में उपयोग करें?

ऐसे समय होते हैं जब OO वास्तव में कोई मतलब नहीं रखता है, और यह उनमें से एक है। हम चाहते हैं कि हमारा कार्यक्रम अन्य कार्यक्रमों के साथ संगत हो, इसलिए हम std::stringएक कक्षा StringUtil_(या कुछ) के साथ रहेंगे ।

यदि आप प्रति कक्षा एक उपयोग के साथ रहना चाहते हैं, तो मैं कहूंगा कि यह सबसे अच्छा है। मैं कहता हूँ कि यह मूर्खता है कि सभी वर्गों के लिए एक उपयोग हो या एक कक्षा के लिए कई बर्तन हों।

Answer 9

यह बहुत आसान है कि किसी उपयोगिता को ब्रांड करें क्योंकि डिजाइनर कोड डालने के लिए उपयुक्त जगह के बारे में नहीं सोच सकता है। अक्सर कुछ सच्चे "उपयोगिताओं" होते हैं।

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

Answer 10

यूटिलिटी स्टैटिक विधियों से युक्त उपयोगिता वर्ग उपयोगी हो सकते हैं। ये अक्सर यूनिट टेस्ट के लिए बहुत आसान होते हैं।

Answer 11

जावा 8 के साथ आप इंटरफेस में स्थिर तरीकों का उपयोग कर सकते हैं ... समस्या हल हो गई है।

Comments

यह stackoverflow.com/a/3340037/2859065

— Luchostein

यह कैसे अलग है कि उन्हें एक कक्षा में रखा जाए और आयात किया जाए?

— विलेमॉल

Answer 12

अधिकांश यूटीएल वर्ग खराब हैं क्योंकि:

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

स्थिर बनाम गतिशील पुस्तकालयों के लिए कुछ उपमाएँ हैं।

Answer 13

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

public static int method01_Account(Object o, String... args) {
    Account acc = (Account)o;
    ...
    return acc.getInt();
}  

Comments

लगता है कि आप मेरे लिए जूनियर हैं ..: पी ऐसा करने के लिए गैर-बुराई तरीका विनम्रता से Accountफ़ाइल को अनलॉक करने के लिए अपने "जूनियर डेवलपर" से पूछना है । या बेहतर, नॉन-लॉकिंग सोर्स कंट्रोल सिस्टम के साथ जाएं।

— सुदीप

मुझे लगता है कि उनका मतलब है कि Accountफाइल को ऐसे लॉक किया गया था कि जूनियर डेवलपर्स इसमें बदलाव नहीं कर सकते। एक जूनियर डेवलपर के रूप में, इसके चारों ओर जाने के लिए, उन्होंने ऊपर की तरह किया। उस ने कहा, अभी भी बेहतर है कि केवल फ़ाइल तक पहुंच प्राप्त करें और इसे ठीक से करें।

— डॉक

इसमें +1 जोड़ना क्योंकि डाउनवोट्स कठोर प्रतीत होते हैं जब किसी को इस बात का पूरा संदर्भ नहीं होता है कि आपने यह उत्तर क्यों दिया है

— joelc

Answer 14

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