अपरिवर्तनीय वस्तुओं के लिए इंटरफेस की घोषणा न करें

Question

अपरिवर्तनीय वस्तुओं के लिए इंटरफेस की घोषणा न करें

[संपादित करें] जहाँ प्रश्न में ऑब्जेक्ट डेटा ट्रांसफर ऑब्जेक्ट्स (DTO) या प्लेन ओल्ड डेटा (PODs) का प्रतिनिधित्व करते हैं

क्या यह एक उचित दिशानिर्देश है?

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

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

इस समस्या के कारण, मैं अपरिवर्तनीय वस्तुओं के लिए इंटरफेस की घोषणा नहीं कर रहा हूँ।

यह यूनिट परीक्षण के संबंध में प्रभाव हो सकता है, लेकिन इसके अलावा, क्या यह एक उचित दिशानिर्देश है?

या क्या एक और पैटर्न है जिसका उपयोग मैं "स्प्रेडिंग-इंटरफ़ेस" समस्या से बचने के लिए कर रहा हूं।

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

[संपादित करें]

वस्तुओं को अपरिवर्तनीय बनाने के इच्छुक मेरे कारणों के लिए बहुत अधिक संदर्भ प्रदान करने के लिए, एरिक लिपर्ट के इस ब्लॉग पोस्ट को देखें:

http://blogs.msdn.com/b/ericlippert/archive/tags/immutability/

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

इसके अलावा जोशुआ बलोच ने अपनी पुस्तक इफेक्टिव जावा में अपरिवर्तनीय वस्तुओं के उपयोग की सिफारिश की है ।

---

जाँच करना

प्रतिक्रिया के लिए धन्यवाद, सभी। मैंने आगे बढ़ने और डीटीओ और उनके ilk के लिए इस दिशानिर्देश का उपयोग करने का निर्णय लिया है। यह अब तक अच्छा काम कर रहा है, लेकिन यह केवल एक सप्ताह रहा है ... फिर भी, यह अच्छा लग रहा है।

इससे संबंधित कुछ अन्य मुद्दे हैं जिनके बारे में मैं पूछना चाहता हूं; विशेष रूप से कुछ मैं "डीप या शेलो इम्यूएबिलिटी" कह रहा हूं (नामकरण मैं दीप और शेलो क्लोनिंग से चुराता हूं) - लेकिन यह एक और समय के लिए एक सवाल है।

Comments

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

— स्टीवन डॉगगार्ट

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

— स्टीवन डॉगगार्ट

मैं उलझन में हूँ, क्यों न सिर्फ इंटरफ़ेस बंद कर दिया जाए? लेकिन दूसरी ओर, मैं उन वस्तुओं के लिए इंटरफेस देखने के लिए टायर करता हूं जो वास्तव में डोमेन ऑब्जेक्ट हैं और / या डीटीओ उन वस्तुओं के लिए कारखानों की आवश्यकता होती है ... मेरे लिए संज्ञानात्मक असंगति का कारण बनता है।

— माइकल ब्राउन

उन कक्षाओं के लिए इंटरफेस के बारे में क्या जो सभी अपरिवर्तनीय हैं? उदाहरण के लिए, जावा के संख्या वर्ग एक एक को परिभाषित करने की अनुमति देता है List<Number>जो कर सकते हैं Integer, Float, Long, BigDecimal, आदि ... जो सब के सब खुद को अपरिवर्तनीय हैं।

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

— विन्गंड्रोइड

Answer 1

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

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

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

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

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

Comments

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

— 20

... डेटा को एक से दूसरे में कॉपी करने का साधन। यदि सभी प्रकारों में कुछ डेटा शामिल हैं, तो इसे पढ़ने के लिए समान इंटरफ़ेस लागू करें, तो ऐसे डेटा को सभी प्रकारों के बीच आसानी से कॉपी किया जा सकता है, प्रत्येक को यह जानने की आवश्यकता के बिना कि प्रत्येक को दूसरे से कैसे आयात किया जाए।

— सुपरकैट

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

— केविन

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

— स्टीवन डॉगगार्ट

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

— स्टीवन डॉगगार्ट

Answer 2

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

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

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

Comments

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

— ट्रैविस पार्क

Answer 3

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

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

Answer 4

कोड कई मामलों में बहुत सरल हो जाता है जब आप जानते हैं कि कुछ अपरिवर्तनीय है - जिसे आप नहीं करते हैं यदि आपको एक इंटरफ़ेस सौंप दिया गया है।

मुझे नहीं लगता कि यह एक चिंता है कि एक्सेसरी कार्यान्वयनकर्ता को इसके बारे में चिंता करना है। यदि interface Xइसका अर्थ अपरिवर्तनीय है, तो क्या यह इंटरफ़ेस इंसट्रक्टर की जिम्मेदारी नहीं है कि वे इस बात का बीमा करें कि वे एक अपरिवर्तनीय तरीके से इंटरफ़ेस को लागू करते हैं या नहीं?

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

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

Comments

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

— विघ्नह्रदय

नहीं तुच्छता, मुझे लगता है कि नहीं है, लेकिन यह एक अपेक्षाकृत सरल सोचा व्यायाम है - अगर MutableObjectहै nतरीकों कि परिवर्तन राज्य और mतरीकों कि वापसी राज्य, ImmutableDecoratorतरीकों का पर्दाफाश करने के लिए जारी कर सकते हैं कि वापसी राज्य ( m), और, पर्यावरण, ज़ोर पर निर्भर करता है या उत्परिवर्तनीय विधियों में से एक कहे जाने पर एक अपवाद को फेंक दें।

— जोनाथन रिच

मैं वास्तव में रन-टाइम अपवाद की संभावना में संकलन-समय निश्चितता को परिवर्तित करना पसंद नहीं करता ...

— मैथ्यू वाटसन

ठीक है, लेकिन ImmutableDecorator यह कैसे जान सकता है कि कोई दी गई विधि राज्य बदलती है या नहीं?

— विन्गंड्रोइड

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

— जोनाथन रिच

Answer 5

आप एक इंटरफ़ेस पास किया जा रहा है, और फिर इसे कुछ कोड को पारित करना चाहते हैं जो वास्तव में यह मान लेना चाहता है कि इसको पारित होने वाली चीज़ अपरिवर्तनीय है।

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

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

अब चलो एरिक के डिजाइन से चिपके हैं। एक ऐसी विधि जिसमें एक अपरिवर्तनीय स्टैक की आवश्यकता होती है, जिसमें Stack<T>सामान्य इंटरफ़ेस के बजाय टाइप का पैरामीटर होना चाहिए IStack<T>जो सामान्य अर्थों में स्टैक के अमूर्त डेटा प्रकार का प्रतिनिधित्व करता है। यह स्पष्ट नहीं है कि एरिक के अपरिवर्तनीय स्टैक का उपयोग करते समय यह कैसे करना है और उन्होंने अपने लेखों में इस पर चर्चा नहीं की, लेकिन यह संभव है। समस्या खाली स्टैक के प्रकार के साथ है। आप यह सुनिश्चित करके इस समस्या को हल कर सकते हैं कि आपको कभी खाली स्टैक नहीं मिलता है। यह स्टैक पर पहले मूल्य के रूप में एक डमी मूल्य को धक्का देकर और इसे कभी भी पॉपिंग करके सुनिश्चित नहीं किया जा सकता है। इस तरह, आप सुरक्षित रूप से के परिणाम डाल सकता Pushहै और Popकरने के लिए Stack<T>।

Stack<T>लागू होने IStack<T>से उपयोगी हो सकता है। आप उन तरीकों को परिभाषित कर सकते हैं जिनके लिए स्टैक की आवश्यकता होती है, किसी भी स्टैक की, जरूरी नहीं कि एक स्टैक योग्य स्टैक हो। इन विधियों में एक प्रकार का पैरामीटर हो सकता है IStack<T>। यह आपको इसके लिए अपरिवर्तनीय स्टैक्स पास करने में सक्षम बनाता है। आदर्श रूप में, IStack<T>मानक पुस्तकालय का ही हिस्सा होगा। .NET में, कोई नहीं है IStack<T>, लेकिन अन्य मानक इंटरफेस हैं जो अपरिवर्तनीय स्टैक लागू कर सकते हैं, जिससे टाइप अधिक उपयोगी हो सकता है।

वैकल्पिक डिजाइन और अपरिवर्तनीय स्टैक का कार्यान्वयन जिसे मैंने पहले संदर्भित किया था, नामक इंटरफ़ेस का उपयोग करता है IImmutableStack<T>। बेशक, इंटरफ़ेस नाम में "अपरिवर्तनीय" सम्मिलित करना हर प्रकार को नहीं बनाता है जो इसे अपरिवर्तनीय बनाता है। हालांकि, इस इंटरफ़ेस में, अपरिवर्तनीयता का अनुबंध सिर्फ मौखिक है। एक अच्छे डेवलपर को इसका सम्मान करना चाहिए।

यदि आप एक छोटा, आंतरिक पुस्तकालय विकसित कर रहे हैं, तो आप इस अनुबंध को सम्मानित करने के लिए टीम पर हर किसी के साथ सहमत हो सकते हैं और आप IImmutableStack<T>मापदंडों के प्रकार के रूप में उपयोग कर सकते हैं । अन्यथा, आपको इंटरफ़ेस प्रकार का उपयोग नहीं करना चाहिए।

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