"जानकारी" प्रत्यय के साथ कक्षाओं के नामकरण के पीछे क्या विचार है, उदाहरण के लिए: "SomeClass" और "SomeClassInfo"?

20

मैं एक ऐसी परियोजना में काम कर रहा हूं, जो भौतिक उपकरणों से संबंधित है, और मैं इस उलझन में हूं कि इस परियोजना में कुछ वर्गों को कैसे ठीक से नाम दिया जाए।

वास्तविक उपकरणों (सेंसर और रिसीवर) को ध्यान में रखते हुए एक बात है, और सॉफ्टवेयर में उनका प्रतिनिधित्व एक और है, मैं "जानकारी" प्रत्यय नाम पैटर्न के साथ कुछ वर्गों के नामकरण के बारे में सोच रहा हूं।

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

लेकिन अब मैं उलझन में हूं, क्योंकि वस्तुओं के जीवनचक्र पर एक मध्यभूमि है जहां मैं यह तय नहीं कर सकता कि मुझे एक या दूसरे का उपयोग करना चाहिए, या दूसरे से एक कैसे प्राप्त करना चाहिए, या यहां तक कि क्या दोनों वेरिएंट को केवल एक वर्ग तक ढह जाना चाहिए।

इसके अलावा, सभी बहुत ही सामान्य उदाहरण Employeeवर्ग स्पष्ट रूप से वास्तविक व्यक्ति का सिर्फ एक प्रतिनिधित्व है, लेकिन कोई भी वर्ग को नाम देने का सुझाव नहीं देगा EmployeeInfo, जहां तक मुझे पता है।

मैं जिस भाषा के साथ काम कर रहा हूं वह .NET है, और यह नामकरण पैटर्न इन वर्गों के साथ छूट के लिए पूरे ढांचे में सामान्य प्रतीत होता है:

Directoryऔर DirectoryInfoकक्षाएं;
Fileऔर FileInfoकक्षाएं;
ConnectionInfoवर्ग (कोई संवाददाता Connectionवर्ग के साथ);
DeviceInfoवर्ग (कोई संवाददाता Deviceवर्ग के साथ);

तो मेरा सवाल है: क्या इस नामकरण पैटर्न का उपयोग करने के बारे में एक सामान्य तर्क है? क्या ऐसे मामले हैं जहां यह नाम ( Thingऔर ThingInfo) और अन्य मामलों के जोड़े हैं जिनके पास केवल अपने समकक्ष के बिना ThingInfoवर्ग, या वर्ग मौजूद होना चाहिए Thing?

— heltonbiker
स्रोत

5

बेन आरोनसन ने अपने जवाब में इसे सही पाया; Infoप्रत्यय एक अलग staticवर्ग अपनी स्टेटफुल समकक्ष से उपयोगिता तरीकों से युक्त। यह इस तरह के रूप में एक "सबसे अच्छा अभ्यास" नहीं है; यह सिर्फ एक तरीका है कि .NET टीम एक विशेष समस्या को हल करने के लिए आई है। वे बस के रूप में आसानी से हो सकता था के साथ आते हैं FileUtilityऔर Fileहै, लेकिन File.DoSomething()और FileInfo.FileNameबेहतर पढ़ने के लिए लग रहे हैं।

— रॉबर्ट हार्वे

1

यह ध्यान देने योग्य है कि यह एक सामान्य पैटर्न है, लेकिन भाषाओं और एपीआई के रूप में कई अलग-अलग नामकरण सम्मेलनों के साथ। जावा में, उदाहरण के लिए, यदि आपके पास एक राज्य वर्ग है Foo, तो आपके पास एक गैर-तात्कालिक उपयोगिता वर्ग हो सकता है Foos। जब नामकरण की बात आती है, तो महत्वपूर्ण चीज एपीआई के भीतर स्थिरता है, और आदर्श रूप से प्लेटफॉर्म पर एपीआई के पार है।

— केविन क्रुमविड ने

1

वास्तव में? "कोई भी वर्ग EmployeeInfo के नाम का सुझाव नहीं देगा" ?? कोई भी नहीं? इतना स्पष्ट नहीं है कि कुछ के लिए थोड़ा मजबूत लगता है।

— thePopMachine

@ ThePopMachine मैं सहमत हूं कि इस मामले में "कोई भी" शब्द बहुत कठिन हो सकता है, लेकिन Employeeउदाहरण दर्जनों या तो ऑनलाइन या क्लासिक पुस्तकों में पाए जाते हैं, जबकि मैंने EmployeeInfoअभी तक नहीं देखा है (शायद इसलिए कि एक कर्मचारी एक जीवित प्राणी है, नहीं एक कनेक्शन या एक फाइल की तरह एक तकनीकी निर्माण)। लेकिन, सहमत, अगर EmployeeInfoकिसी परियोजना में कक्षा प्रस्तावित की जानी थी, तो मेरा मानना है कि इसका उपयोग हो सकता है।

— हेलटनबीकर

1

chegg.com/homework-help/questions-and-answers/... mathworks.com/help/matlab/matlab_oop/... stackoverflow.com/questions/22082434/binarytree-employee-class cplusplus.com/forum/general/24222

— ThePopMachine

21

मुझे लगता है कि "जानकारी" एक मिथ्या नाम है। वस्तुओं में राज्य और क्रियाएं होती हैं: "सूचना" "राज्य" के लिए सिर्फ एक और नाम है जो पहले से ही ओओपी में बेक किया गया है।

आप वास्तव में यहाँ क्या करने की कोशिश कर रहे हैं? आपको एक ऑब्जेक्ट की आवश्यकता है जो सॉफ़्टवेयर में हार्डवेयर का प्रतिनिधित्व करता है इसलिए अन्य कोड इसका उपयोग कर सकते हैं।

यह कहना आसान है लेकिन जैसा आपको पता चला है, उससे कहीं अधिक है। "हार्डवेयर का प्रतिनिधित्व करना" आश्चर्यजनक रूप से व्यापक है। एक वस्तु जो कई चिंताओं को करती है:

निम्न-स्तरीय डिवाइस संचार, चाहे वह यूएसबी इंटरफ़ेस, एक सीरियल पोर्ट, टीसीपी / आईपी, या मालिकाना कनेक्शन से बात कर रहा हो।
प्रबंध करने की अवस्था। डिवाइस चालू है? सॉफ्टवेयर से बात करने के लिए तैयार हैं? व्यस्त?
घटनाओं को संभालना। डिवाइस ने डेटा का उत्पादन किया: अब हमें रुचि रखने वाले अन्य वर्गों को पास करने के लिए घटनाओं को उत्पन्न करने की आवश्यकता है।

कुछ उपकरण जैसे कि सेंसर में प्रिंटर / स्कैनर / फैक्स मल्टीफ़ंक्शन डिवाइस की तुलना में कम चिंताएँ होंगी। एक सेंसर की संभावना सिर्फ एक बिट स्ट्रीम का उत्पादन करती है, जबकि एक जटिल डिवाइस में जटिल प्रोटोकॉल और इंटरैक्शन हो सकते हैं।

वैसे भी, आपके विशिष्ट प्रश्न पर वापस, आपकी विशिष्ट आवश्यकताओं के साथ-साथ हार्डवेयर इंटरैक्शन की जटिलता के आधार पर ऐसा करने के कई तरीके हैं।

यहाँ एक उदाहरण दिया गया है कि मैं एक तापमान सेंसर के लिए वर्ग पदानुक्रम कैसे डिजाइन करूंगा:

ITENSSource: इंटरफ़ेस जो किसी भी चीज़ का प्रतिनिधित्व करता है जो तापमान डेटा का उत्पादन कर सकता है: एक सेंसर, यहां तक कि एक फ़ाइल आवरण या हार्ड-कोडेड डेटा भी हो सकता है (सोचें: नकली परीक्षण)।
Acme4680Sensor: ACME मॉडल 4680 सेंसर (रोडरनर पास होने पर पता लगाने के लिए महान)। यह कई इंटरफेस को लागू कर सकता है: शायद यह सेंसर तापमान और आर्द्रता दोनों का पता लगाता है। इस ऑब्जेक्ट में प्रोग्राम-स्तरीय स्थिति शामिल है जैसे "सेंसर जुड़ा हुआ है?" और "अंतिम पठन क्या था?"
Acme4680SensorComm: केवल भौतिक डिवाइस के साथ संचार करने के लिए उपयोग किया जाता है। यह ज्यादा राज्य बनाए नहीं रखता है। इसका उपयोग संदेश भेजने और प्राप्त करने के लिए किया जाता है। यह उन प्रत्येक संदेशों के लिए C # विधि है, जिन्हें हार्डवेयर समझता है।
HardwareManager: उपकरणों को प्राप्त करने के लिए उपयोग किया जाता है। यह अनिवार्य रूप से एक कारखाना है जो कैश का उदाहरण देता है: प्रत्येक हार्डवेयर डिवाइस के लिए डिवाइस ऑब्जेक्ट का केवल एक उदाहरण होना चाहिए। यह जानने के लिए पर्याप्त स्मार्ट होना चाहिए कि यदि थ्रेड ए एसीएमई तापमान संवेदक का अनुरोध करता है और थ्रेड बी एसीएमई आर्द्रता सेंसर का अनुरोध करता है, तो ये वास्तव में एक ही वस्तु हैं और दोनों थ्रेड्स में वापस आ जाना चाहिए।

शीर्ष स्तर पर आपके पास प्रत्येक हार्डवेयर प्रकार के लिए इंटरफेस होगा। वे C # डेटा प्रकारों का उपयोग करके आपके C # कोड की कार्रवाइयों का वर्णन करते हैं (उदाहरण के लिए बाइट सरणियाँ जो कच्चे डिवाइस ड्राइवर उपयोग करते हैं)।

उसी स्तर पर आपके पास प्रत्येक हार्डवेयर प्रकार के लिए एक उदाहरण के साथ एक गणन वर्ग है। तापमान सेंसर एक प्रकार का हो सकता है, नमी सेंसर दूसरा।

इसके नीचे एक स्तर वास्तविक वर्ग हैं जो उन इंटरफेस को लागू करते हैं: वे एक डिवाइस का प्रतिनिधित्व करते हैं जो कि ऊपर वर्णित Acme4680Sensor के समान है। यदि डिवाइस कई कार्य कर सकता है तो कोई विशेष वर्ग कई इंटरफेस को लागू कर सकता है।

प्रत्येक डिवाइस वर्ग की अपनी निजी कॉम (संचार) कक्षा होती है जो हार्डवेयर से बात करने के निम्न-स्तरीय कार्य को संभालती है।

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

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

यूएमएल वर्ग आरेख उदाहरण इस उत्तर में वर्णित डिजाइन दिखा रहा है

नोट: HardwareManager और प्रत्येक डिवाइस वर्ग के बीच ऐसे संघ हैं जो मुझे आकर्षित नहीं करते थे क्योंकि आरेख तीर के सूप में बदल जाता था।

बहुत दिलचस्प जवाब। मैं एक त्वरित संपादन के लिए कहूंगा: आपके द्वारा उल्लिखित चार वर्गों के बीच विरासत / नियंत्रण / सहयोग क्या है और अधिक स्पष्ट छोड़ दें। आपका बहुत बहुत धन्यवाद!

— हेलटनबीकर

मैंने एक यूएमएल श्रेणी आरेख जोड़ा। क्या यह मदद करता है?

2

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

— हेलटनबीकर

जब मैंने उस प्रश्न को पढ़ा तो मुझे महसूस हुआ कि वहाँ कुछ और चल रहा था, इसलिए मैं थोड़ा आगे निकल गया और पूरे डिजाइन को साझा किया। यह एक सरल नामकरण समस्या से अधिक है क्योंकि नाम डिजाइन के सूचक हैं। मैंने इस तरह से निर्मित प्रणालियों के साथ काम किया है और उन्होंने काफी अच्छा काम किया है।

11

यहां एकल एकीकरण सम्मेलन को ढूंढना थोड़ा मुश्किल हो सकता है क्योंकि ये वर्ग कई नामस्थानों पर फैले हुए हैं, ( ConnectionInfoलगता है कि इन CrystalDecisionsऔर DeviceInfoइन System.Reporting.WebForms)।

इन उदाहरणों को देखते हुए, हालांकि, प्रत्यय के दो अलग-अलग उपयोग प्रतीत होते हैं:

एक कक्षा को विशिष्ट तरीके प्रदान करने वाले वर्ग के साथ स्थिर तरीके प्रदान करना। यह System.IOवर्गों के लिए मामला है , जैसा कि उनके विवरण द्वारा रेखांकित किया गया है:

निर्देशिका :

निर्देशिकाओं और उपनिर्देशिकाओं के माध्यम से बनाने, आगे बढ़ने और गणना करने के लिए स्थिर तरीकों का प्रस्ताव करता है। इस वर्ग को विरासत नहीं बनाया जा सकता।

DirectoryInfo :

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

Infoयहाँ थोड़ा विषम विकल्प लगता है, लेकिन यह अंतर को अपेक्षाकृत स्पष्ट करता है: एक Directoryवर्ग किसी भी राज्य को पकड़े बिना सामान्य रूप से या तो किसी विशेष निर्देशिका का प्रतिनिधित्व कर सकता है या सामान्य निर्देशिका-संबंधी सहायक तरीके प्रदान DirectoryInfoकर सकता है , जबकि वास्तव में केवल पूर्व हो सकता है।
जोर देकर कहा कि वर्ग केवल जानकारी रखता है और वह व्यवहार प्रदान नहीं करता है जो बिना प्रत्यय के नाम से अपेक्षित हो सकता है ।

मुझे लगता है कि उस वाक्य का अंतिम हिस्सा उस पहेली का टुकड़ा हो सकता है जो अलग-अलग होती है, कहती है, ConnectionInfoसे EmployeeInfo। अगर मुझे एक वर्ग कहा जाता है Connection, तो मैं उचित रूप से यह अपेक्षा करूँगा कि वास्तव में मुझे वह कार्यक्षमता प्रदान करें जो एक कनेक्शन की है- मैं उन तरीकों की तलाश करूँगा void Open(), आदि, हालाँकि, उनके सही दिमाग में कोई भी उम्मीद नहीं करेगा कि वास्तव में एक Employeeवर्ग हो सकता है। क्या कोई वास्तविक कर Employeeकी तरह तरीकों के लिए दिखता है, या void DoPaperwork()या bool TryDiscreetlyBrowseFacebook()।

— बेन आरोनसन
स्रोत

1

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

— हेल्टनबाइकर

4

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

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

कई मामलों में, संसाधन से जुड़ी वस्तुओं को तब साफ किया जाना चाहिए जब उनकी सेवाओं की आवश्यकता नहीं होती है। क्योंकि *Infoऑब्जेक्ट संसाधनों से नहीं जुड़ते हैं, उन्हें सफाई की आवश्यकता नहीं होती है। परिणामस्वरूप, उन मामलों में जहां कोई Infoवस्तु ग्राहक की आवश्यकताओं को पूरा करेगी, कोड का उपयोग करने से बेहतर है कि किसी वस्तु का उपयोग किया जाए जो अंतर्निहित संसाधन का प्रतिनिधित्व करता है, लेकिन जिसका उस संसाधन से कनेक्शन साफ करना होगा।

— supercat
स्रोत

1

यह बिल्कुल गलत नहीं है, लेकिन यह .NET के नामकरण पैटर्न को बहुत अच्छी तरह से समझाता नहीं है, क्योंकि Fileक्लास को तत्काल नहीं किया जा सकता है और FileInfoऑब्जेक्ट अंतर्निहित फाइल सिस्टम के साथ अपडेट करते हैं ।

— नाथन तुग्गी

@NathanTuggy मैं मानता हूं कि यह .NET में इस नामकरण सम्मेलन के साथ अच्छी तरह से संबंधित नहीं है, लेकिन मेरी वर्तमान समस्या के बारे में, मेरा मानना है कि यह बहुत प्रासंगिक है और एक सुसंगत समाधान को प्रेरित कर सकता है। मैंने इस उत्तर को

— उकेरा

@NathanTuggy: मैं किसी भी प्रकार की स्थिरता के मॉडल के रूप में .NET का उपयोग करने की अनुशंसा नहीं करूंगा। यह एक अच्छा और उपयोगी फ्रेमवर्क है जो बहुत सारे अच्छे विचारों को समेटता है, लेकिन कुछ बुरे विचारों को मिक्स में भी पकड़ लिया जाता है।

— सुपरकैट

@ सुपरकैट: श्योर; यह सिर्फ "क्यों .NET करता है इस बारे में एक सवाल का जवाब देने के लिए अजीब लगता है?" "यह% THIS_WAY%% करने के लिए एक अच्छा विचार होगा"।

— नाथन तुग्गी 19

@NathanTuggy: मुझे सवाल में कक्षाओं के सटीक विवरण याद नहीं थे, लेकिन मुझे लगा कि FileInfoकेवल सांख्यिकीय रूप से कैप्चर की गई जानकारी है। क्या यह नहीं? इसके अलावा, मेरे पास कभी भी गैर-अनन्य मोड में फाइलें खोलने का अवसर नहीं था, लेकिन यह संभव होना चाहिए, और मैं वहां एक ऐसी विधि मौजूद होने की उम्मीद करूंगा, जो किसी फ़ाइल के वर्तमान आकार की रिपोर्ट करेगी, भले ही खोलने के लिए उपयोग की गई वस्तु न हो कहा जाता है File(आम तौर पर मैं सिर्फ का उपयोग ReadAllBytes, WriteAllBytes, ReadAllText, WriteAllText, आदि)।

— सुपरकैट

2

वास्तविक उपकरणों (सेंसर और रिसीवर) को ध्यान में रखते हुए एक बात है, और सॉफ्टवेयर में उनका प्रतिनिधित्व एक और है, मैं "जानकारी" प्रत्यय नाम पैटर्न के साथ कुछ वर्गों के नामकरण के बारे में सोच रहा हूं।

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

मुझे यह भेद पसंद नहीं है। सभी वस्तुएँ सॉफ़्टवेयर में "प्रतिनिधित्व [s] हैं।" "वस्तु" शब्द का यही अर्थ है।

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

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

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

— केविन
स्रोत

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

— हेल्टनबाइकर

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

— केविन

1

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

— हेल्टनबाइकर

2

मैं कहूंगा कि संदर्भ / डोमेन मायने रखता है, क्योंकि हमारे पास उच्च स्तरीय व्यापार तर्क कोड और निम्न स्तर के मॉडल, वास्तुकला घटक और इतने पर हैं ...

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

व्यवसाय डोमेन का वर्ग नाम ऐसा होना चाहिए कि सभी हितधारक इसके बारे में बात करें, भले ही यह अजीब लगे या 100% सही भाषा न हो।

डेटा संरचनाओं के लिए अच्छे प्रत्यय उदाहरण के लिए 'लिस्ट', 'मैप' और 'डेकोरेटर', 'एडेप्टर' को इंगित करने के लिए हैं, अगर आपको लगता है कि यह आवश्यक है।

आपके सेंसर परिदृश्य के लिए, मुझे SensorInfoआपके सेंसर क्या है, इसे बचाने की उम्मीद नहीं होगी SensorSpec। Infoimho एक व्युत्पन्न जानकारी है, जैसे FileInfoआकार की तरह कुछ है, आप सहेजते नहीं हैं या फ़ाइलपथ जो पथ और फ़ाइल नाम से बनाया गया है, आदि।

और दूसरी बात:

कंप्यूटर साइंस में केवल दो कठिन चीजें हैं: कैश अमान्यकरण और नामकरण की चीजें।

- फिल कार्लटन

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

— Aitch
स्रोत

1

ThingInfo थिंग के लिए केवल एक महान रीड प्रॉक्सी के रूप में सेवा कर सकता है।

http://www.dofactory.com/net/proxy-design-pattern देखें

प्रॉक्सी: "किसी अन्य वस्तु के लिए एक सरोगेट या प्लेसहोल्डर प्रदान करें ताकि उस तक पहुंच को नियंत्रित किया जा सके।"

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

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

— Shmoken
स्रोत

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

— हेलटनबीकर

(जारी ...) वह यह है: मैं खुद सेंसर से बात नहीं करता, मैं केवल उच्च-स्तरीय कमांड के माध्यम से रिसीवर से बात करता हूं, और रिसीवर बदले में प्रत्येक सेंसर से बात करता है। लेकिन मुझे अंततः संवेदकों से जानकारी की आवश्यकता है, जो मुझे प्राप्तकर्ता उदाहरण से इसकी आसानी से List<SensorInfo>संपत्ति के माध्यम से मिलती है ।

— हेल्टनबीकर

1

इस नामकरण सम्मेलन के वास्तविक कारण पर अभी तक किसी को भी यह सवाल नहीं उठा है।

A डायरेक्टरी DirectoryInfoनहीं है । यह निर्देशिका के बारे में डेटा के साथ एक डीटीओ है । एक ही निर्देशिका का वर्णन करने वाले ऐसे कई उदाहरण हो सकते हैं। यह कोई इकाई नहीं है। यह एक थ्रोट-वैल्यू ऑब्जेक्ट है। A वास्तविक निर्देशिका का प्रतिनिधित्व नहीं करता है। आप इसे डायरेक्टरी के लिए हैंडल या कंट्रोलर के रूप में भी सोच सकते हैं।DirectoryInfo

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

बीसीएल में वास्तव में एक उदाहरण है जहां दोनों वर्ग मौजूद हैं: ए ServiceControllerएक वर्ग है जो विंडोज सेवा का वर्णन करता है। प्रत्येक सेवा के लिए ऐसे नियंत्रकों की संख्या हो सकती है। एक ServiceBase(या एक व्युत्पन्न वर्ग) है वास्तविक सेवा है और यह धारणात्मक मतलब नहीं है अलग सेवा प्रति इसके बारे में अनेक उदाहरण सामने आना।

— usr
स्रोत

यह Proxy@Shmoken द्वारा उल्लिखित पैटर्न के समान लगता है , है ना?

— हेल्टनबाइकर

@heltonbiker जरूरी नहीं कि यह एक प्रॉक्सी हो। यह एक वस्तु हो सकती है जो किसी भी तरह से उस चीज़ से जुड़ी नहीं है जो इसका वर्णन करती है। उदाहरण के लिए, आप EmployeeInfoवेब सेवा से प्राप्त कर सकते हैं । वह छद्म नहीं है। इसके अलावा उदाहरण: एक AddressInfoभी नहीं है है एक पते एक इकाई नहीं है, क्योंकि एक बात यह प्रॉक्सी कर सकते हैं। यह एक स्टैंड-अलोन मूल्य है।

— usr

1

मैं देख रहा हूँ, यह समझ में आता है!

— हेल्टनबाइकर