design patterns नामकरण वर्ग-सबकुछ "<whatEver> प्रबंधक" को कॉल करने से कैसे बचें?




design-patterns oop (9)

बहुत समय पहले मैंने एक लेख पढ़ा है (मुझे एक ब्लॉग एंट्री माना जाता है) जिसने मुझे नामकरण वस्तुओं पर "दाएं" ट्रैक पर रखा है: अपने प्रोग्राम में चीजों को नाम देने के बारे में बहुत ही विनम्र रहें।

उदाहरण के लिए यदि मेरा एप्लिकेशन (एक सामान्य व्यवसाय ऐप के रूप में) उपयोगकर्ताओं, कंपनियों और पतों को संभालने वाला था, तो मेरे पास एक User , एक Company और एक Address डोमेन क्लास होगा - और शायद कहीं User , एक Company AddressManager और पता AddressManager उस हैंडल को पॉप अप करेगा उन चीजों।

तो क्या आप बता सकते हैं कि उन UserManager AddressManager , CompanyManager AddressManager और पता AddressManager क्या करते हैं? नहीं, क्योंकि प्रबंधक एक बहुत ही सामान्य शब्द है जो आपके डोमेन ऑब्जेक्ट्स के साथ कुछ भी कर सकता है।

मैंने जो लेख पढ़ा है वह बहुत विशिष्ट नामों का उपयोग करके अनुशंसित है। यदि यह एक सी ++ एप्लिकेशन था और उपयोगकर्ता UserManager की नौकरी को ढेर से उपयोगकर्ताओं को आवंटित और मुक्त कर दिया गया था तो यह उपयोगकर्ताओं का प्रबंधन नहीं करेगा बल्कि उनके जन्म और मृत्यु की रक्षा करेगा। हम्म, शायद हम इसे एक UserShepherd

या शायद UserManager का काम प्रत्येक उपयोगकर्ता ऑब्जेक्ट के डेटा की जांच करना और क्रिप्टोग्राफ़िक रूप से डेटा पर हस्ताक्षर करना है। फिर हमारे पास UserRecordsClerk

अब यह विचार मेरे साथ फंस गया है, मैं इसे लागू करने की कोशिश करता हूं। और यह सरल विचार आश्चर्यजनक रूप से कठिन लगता है।

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

आखिर में मैं अपने दिमाग में पैटर्न कैटलॉग की तरह कुछ लेना चाहता हूं (अक्सर डिज़ाइन पैटर्न आसानी से ऑब्जेक्ट नाम प्रदान करते हैं, उदाहरण के लिए एक कारखाना )

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

  • आदि आदि।

तो, आप इस मुद्दे को कैसे संभालेंगे? क्या आपके पास एक निश्चित शब्दावली है, क्या आप फ्लाई पर नए नामों का आविष्कार करते हैं या क्या आप चीजों का नामकरण करना महत्वपूर्ण या गलत नहीं मानते हैं?

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

अद्यतन: उत्तरों का सारांश

इस दौरान इस प्रश्न से मैंने जो कुछ सीखा, उसका संक्षिप्त सारांश यहां दिया गया है।

  • नए रूपकों (नानी) बनाने की कोशिश न करें
  • देखें कि अन्य ढांचे क्या करते हैं

इस विषय पर आगे के लेख / पुस्तकें:

और उत्तर से उपसर्ग / प्रत्यय नाम की एक वर्तमान सूची (विषयपरक!):

  • समन्वयक
  • निर्माता
  • लेखक
  • पाठक
  • हैंडलर
  • पात्र
  • मसविदा बनाना
  • लक्ष्य
  • कनवर्टर
  • नियंत्रक
  • राय
  • फ़ैक्टरी
  • सत्ता
  • बाल्टी

और सड़क के लिए एक अच्छी टिप:

नामकरण पक्षाघात मत बनो। हां, नाम बहुत महत्वपूर्ण हैं लेकिन वे बड़ी मात्रा में बर्बाद करने के लिए पर्याप्त महत्वपूर्ण नहीं हैं। यदि आप 10 मिनट में अच्छा नाम नहीं सोच सकते हैं, तो आगे बढ़ें।

https://code.i-harness.com


अगर हम असली दुनिया को सही तरीके से मॉडल करते हैं तो हम किसी भी xxxFactory , xxxManager या xxxRepository कक्षाओं के बिना कर सकते हैं:

Universe.Instance.Galaxies["Milky Way"].SolarSystems["Sol"]
        .Planets["Earth"].Inhabitants.OfType<Human>().WorkingFor["Initech, USA"]
        .OfType<User>().CreateNew("John Doe");

;-)


आप source-code-wordle.de पर एक नज़र source-code-wordle.de सकते हैं, मैंने .NET ढांचे और कुछ अन्य पुस्तकालयों के वर्ग नामों के सबसे अधिक उपयोग किए जाने वाले प्रत्यय का विश्लेषण किया है।

शीर्ष 20 हैं:

  • गुण
  • प्रकार
  • सहायक
  • संग्रह
  • कनवर्टर
  • हैंडलर
  • जानकारी
  • प्रदाता
  • अपवाद
  • सर्विस
  • तत्त्व
  • प्रबंधक
  • नोड
  • विकल्प
  • फ़ैक्टरी
  • प्रसंग
  • मद
  • डिजाइनर
  • आधार
  • संपादक

जब मैं खुद को कक्षा के नाम में Manager या Helper का उपयोग करने के बारे में सोचता हूं, तो मुझे लगता है कि यह एक कोड गंध है जिसका अर्थ है कि मुझे अभी तक सही अमूर्तता नहीं मिली है और / या मैं एक जिम्मेदारी सिद्धांत का उल्लंघन कर रहा हूं, इसलिए पुनः प्रयास करना और अधिक प्रयास करना डिजाइन में अक्सर नामकरण बहुत आसान बनाता है।

लेकिन यहां तक ​​कि अच्छी तरह से डिज़ाइन किए गए वर्ग स्वयं (हमेशा) नाम नहीं देते हैं, और आपके विकल्प आंशिक रूप से इस पर निर्भर करते हैं कि आप व्यवसाय मॉडल कक्षाएं या तकनीकी आधारभूत संरचना कक्षाएं बना रहे हैं या नहीं।

बिजनेस मॉडल कक्षाएं कठिन हो सकती हैं, क्योंकि वे प्रत्येक डोमेन के लिए अलग हैं। ऐसे कुछ शब्द हैं जिनका मैं बहुत उपयोग करता हूं, जैसे किसी डोमेन के भीतर रणनीति वर्गों की Policy (उदाहरण के लिए, LateRentalPolicy ), लेकिन ये आम तौर पर " सर्वव्यापी भाषा " बनाने की कोशिश करने से बहती हैं जिन्हें आप व्यवसाय उपयोगकर्ताओं के साथ साझा कर सकते हैं, कक्षाओं को डिजाइन और नामकरण कर सकते हैं ताकि वे मॉडल वास्तविक दुनिया के विचार, वस्तुओं, कार्यों, और घटनाओं।

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


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

मैं खुद मुखौटा-पैटर्न का बहुत उपयोग कर रहा हूं (कम से कम, मुझे लगता है कि यह वही है जिसे इसे कहा जाता है)। मेरे पास एक User कक्षा हो सकती है जो केवल एक उपयोगकर्ता का वर्णन करती है, और एक Users वर्ग जो मेरे "उपयोगकर्ताओं के संग्रह" का ट्रैक रखती है। मैं कक्षा को उपयोगकर्ता प्रबंधक नहीं कहता क्योंकि मुझे वास्तविक जीवन में प्रबंधकों को पसंद नहीं है और मैं उन्हें याद दिलाना नहीं चाहता हूं :) बस बहुवचन रूप का उपयोग करके मुझे यह समझने में मदद मिलती है कि कक्षा क्या करती है।


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

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

जानकारी के लिए डिज़ाइन पैटर्न जैसे पुस्तक देखें, यह एक उत्कृष्ट पुस्तक है और आप इसे साफ़ करने में मदद कर सकते हैं जहां आप अपने कोड के साथ रहना चाहते हैं - यदि आप पहले से इसका उपयोग नहीं कर रहे हैं! ; ओ)

मुझे लगता है कि आपका पैटर्न अच्छी तरह से चुना गया है और जहां तक ​​उचित है, तब तक उपयोग किया जाता है, तो सुंदर अनौपचारिक सीधा वर्ग नाम पर्याप्त होना चाहिए!


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

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

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


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


यह किसी चीज के लिए एक फिसलन ढलान की तरह लगता है जो thedailywtf.com पर पोस्ट किया जाएगा, "प्रबंधकऑफ लोग लोगहोव मॉर्टगेज" इत्यादि।

मुझे लगता है कि यह सही है कि एक मोनोलिथिक प्रबंधक वर्ग अच्छा डिज़ाइन नहीं है, लेकिन 'प्रबंधक' का उपयोग करना बुरा नहीं है। UserManager के बजाय हम इसे UserAccountManager, UserProfileManager, UserSecurityManager, आदि पर तोड़ सकते हैं।

'प्रबंधक' एक अच्छा शब्द है क्योंकि यह स्पष्ट रूप से दिखाता है कि एक वर्ग वास्तविक दुनिया की चीज़ का प्रतिनिधित्व नहीं कर रहा है। 'लेखाकार' - मुझे यह कैसे बताना चाहिए कि क्या वह कक्षा है जो उपयोगकर्ता डेटा प्रबंधित करती है, या किसी ऐसे व्यक्ति का प्रतिनिधित्व करती है जो अपने काम के लिए खाता क्लर्क है?


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





naming