टाइपस्क्रिप्ट के लिए इंटरफ़ेस और क्लास कोडिंग दिशानिर्देशों के बारे में भ्रमित

Question

मैं टाइपस्क्रिप्ट कोडिंग दिशानिर्देशों के माध्यम से पढ़ता हूं

और मुझे यह कथन हैरान करने वाला लगा:

इंटरफ़ेस नामों के लिए उपसर्ग के रूप में "I" का उपयोग न करें

मेरा मतलब है कि ऐसा कुछ "मैं" उपसर्ग के बिना बहुत मायने नहीं रखेगा

class Engine implements IEngine

क्या मुझसे साफ़ - साफ़ कुछ चीज़ चूक रही है?

एक और बात जो मुझे समझ में नहीं आई वह थी:

कक्षाओं

स्थिरता के लिए, कोर कंपाइलर पाइपलाइन में कक्षाओं का उपयोग न करें। इसके बजाय फ़ंक्शन क्लोजर का उपयोग करें।

क्या वह राज्य है जो मुझे कक्षाओं का उपयोग नहीं करना चाहिए?

आशा है कि कोई मेरे लिए इसे साफ कर सकता है :)

Comments

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

— ब्रोको

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

— जॉन प्रीस

हाँ, वे सिर्फ दिशा-निर्देश हैं। लेकिन ज्यादातर समय गाइडलाइन के पीछे एक अच्छा कारण होता है। तो बस क्या आप एक प्रोग्रामर के रूप में विकसित करने के लिए इस्तेमाल नहीं कर रहे हैं करने के लिए चिपके :)

— Snjbjørn

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

— स्टानिस्लाव बेरकोव

VSCode में, यदि आप टाइप करते हैं let engine = new E..., तो केवल कक्षाएँ स्वतः सुझाई जाएंगी। इंटरफेस नहीं होगा एहसास नहीं था कि - यह एक कारण है कि मैं 'मैं' के साथ उपसर्ग कर रहा था

— ड्रेनई

Answer 1

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

यह मेरी दृष्टि है कि टाइपस्क्रिप्ट टीम क्यों नहीं I-प्रूफिंग इंटरफेस की सिफारिश करती है।

कारण # 1 हंगेरियन अंकन के समय बीत चुके हैं

I-इंटरफ़िक्स-फ़ॉर-इंटरफ़ेस समर्थकों से मुख्य तर्क यह है कि प्रीफ़िक्सिंग तुरंत ग्रॉकिंग (पीकिंग) के लिए सहायक है कि क्या प्रकार एक इंटरफ़ेस है। कथन है कि उपसर्ग तुरंत ग्रैकिंग के लिए मददगार है (झांकना) हंगेरियन अंकन की एक अपील है । Iइंटरफ़ेस नाम के लिए उपसर्ग, Cवर्ग के लिए, Aसार वर्ग के लिए, sस्ट्रिंग चर के लिए, cकांस्टेबल चर के लिए, iपूर्णांक चर के लिए। मैं मानता हूं कि इस तरह की नाम सजावट आपको पहचानकर्ता पर माउस लहराए बिना या हॉट-की के माध्यम से परिभाषा टाइप करने के लिए नेविगेट करने के बिना जानकारी प्रदान कर सकती है। यह छोटा सा लाभ हंगेरियन नोटेशन द्वारा दिया गया है नुकसान और अन्य कारणों से उल्लिखित है। समकालीन रूपरेखा में हंगेरियन नोटेशन का उपयोग नहीं किया जाता है। सी # हैIऐतिहासिक कारणों (COM) के कारण इंटरफेस के लिए उपसर्ग (और यह C # में एकमात्र उपसर्ग है)। .NET आर्किटेक्ट में से एक में (ब्रैड अब्राम) को लगता है कि यह उपसर्ग का उपयोग नहीं करनाI बेहतर होता । टाइपस्क्रिप्ट COM-लीगेसी-मुक्त है, क्योंकि इसमें नो I-प्रिफ़िक्स-फॉर-इंटरफ़ेस नियम है।

कारण # 2 I-विक्षेप उपसर्ग सिद्धांत का उल्लंघन करता है

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

उदाहरण: मान लें कि आपको एपीआई डिजाइन मिथक को ठीक करने की आवश्यकता है : अपने कोड में अनुबंध के रूप में ICarइंटरफ़ेस जैसे इंटरफ़ेस हटाएं और Carइसके बजाय आधार-वर्ग का उपयोग करें। फिर आपको सभी उपभोक्ताओं में ऐसा प्रतिस्थापन करने की आवश्यकता है। I-निफिक्स ब्लैक-बॉक्स कार्यान्वयन विवरण पर उपभोक्ताओं की अंतर्निहित निर्भरता की ओर जाता है।

कारण # 3 बुरे नामकरण से सुरक्षा

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

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

अच्छा उदाहरण: WpfeServerAutosuggestManager implements AutosuggestManager, FileBasedAutosuggestManager implements AutosuggestManager।

खराब उदाहरण AutosuggestManager implements IAutosuggestManager:।

कारण # 4 उचित रूप से चुने गए नाम आपको एपीआई डिजाइन मिथक: अनुबंध के रूप में इंटरफ़ेस के खिलाफ टीकाकरण करते हैं ।

मेरे व्यवहार में, मैंने बहुत से ऐसे लोगों से मुलाकात की, जिन्होंने Car implements ICarनामकरण योजना वाले एक अलग इंटरफ़ेस में एक वर्ग के इंटरफ़ेस रहित भाग को नकल किया । अलग इंटरफ़ेस प्रकार में एक वर्ग का डुप्लिकेट इंटरफ़ेस हिस्सा जादुई रूप से इसे अमूर्त में नहीं बदलता है। आपको अभी भी ठोस कार्यान्वयन मिलेगा लेकिन डुप्लिकेट इंटरफ़ेस इंटरफ़ेस के साथ। यदि आपका एब्स्ट्रैक्शन इतना अच्छा नहीं है, तो इंटरफ़ेस पार्ट को डुप्लिकेट करना किसी भी तरह से इसमें सुधार नहीं करेगा। अमूर्तन निकालना कठिन काम है।

नोट: TS में आपको मॉकिंग क्लासेस या ओवरलोडिंग कार्यक्षमता के लिए अलग इंटरफ़ेस की आवश्यकता नहीं है। एक अलग इंटरफ़ेस बनाने के बजाय जो किसी वर्ग के सार्वजनिक सदस्यों का वर्णन करता है आप टाइपस्क्रिप्ट उपयोगिता प्रकारों का उपयोग कर सकते हैं । Eg Required<T>एक प्रकार का निर्माण करता है जिसमें सभी प्रकार के सार्वजनिक सदस्य होते हैं T।

export class SecurityPrincipalStub implements Required<SecurityPrincipal> {
  public isFeatureEnabled(entitlement: Entitlement): boolean {
      return true;
  }
  public isWidgetEnabled(kind: string): boolean {
      return true;
  }

  public areAdminToolsEnabled(): boolean {
      return true;
  }
}

यदि आप कुछ सार्वजनिक सदस्यों को छोड़कर एक प्रकार का निर्माण करना चाहते हैं तो आप ओमिट और बहिष्कृत के संयोजन का उपयोग कर सकते हैं ।

Comments

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

— cchamberlain

@demisx अगर यह अजीब लगता है तो आपको ऐसा नहीं करना चाहिए। प्रश्न का उत्तर दें: क्या आपको वास्तव में उनकी आवश्यकता है? क्या वे किसी भी तरह का सेंस करते हैं या आप उनका इस्तेमाल सिर्फ सही इंजीनियरिंग करने की झूठी समझ के लिए करते हैं?

— स्टानिस्लाव बेरकोव

जबकि आपके अंक सिद्धांत रूप में अच्छे लगते हैं, वास्तविकता यह है कि "I" उपसर्ग अक्सर "Impl" प्रत्यय के लिए बड़े पर्याप्त टीमों में बदले

— jameslk

@jameslk मैं चीजों को बिना नाम के जानता हूं Iऔर Implयह कठिन है ("कंप्यूटर साइंस में केवल दो कठिन चीजें हैं: कैश अमान्य और नामकरण की चीजें" - फिल कार्लटन) लेकिन यह उल्लेखनीय है।

— स्टैनिस्लाव बेरकोव

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

— क्रिस

Answer 2

आपके द्वारा संदर्भित लिंक के बारे में स्पष्टीकरण:

यह टाइपस्क्रिप्ट के लिए कोड की शैली के बारे में दस्तावेज़ीकरण है, न कि आपकी परियोजना को कैसे लागू किया जाए इसके लिए एक शैली दिशानिर्देश।

यदि Iउपसर्ग का उपयोग करने से आपको और आपकी टीम को समझ में आता है, तो इसका उपयोग करें (I do)।

यदि नहीं, (शायद SomeThing) जावा शैली (इंटरफ़ेस) के साथ SomeThingImpl(कार्यान्वयन) तो हर तरह से उपयोग करें।

Comments

सिर्फ स्पष्टीकरण के लिए। टाइपस्क्रिप्ट हैंडबुक अभी भी कहता है: In general, do not prefix interfaces with I (e.g. IColor). Because the concept of an interface in TypeScript is much more broad than in C# or Java, the IFoo naming convention is not broadly useful.यह सख्त नहीं है, लेकिन मजबूत सिफारिश की तरह दिखता है।

— गुरिया

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

— 15

वहाँ परिदृश्य है कि मुझे लगता है कि रखने के लिए समझ में आता है I। एक प्रतिक्रिया परियोजना Cardमें एक इंटरफ़ेस और एक घटक है जिसे कहा जाता है Card। सहारा में मैं एक सरणी की जरूरत है Card, लेकिन घटक घटक नहीं है। मुझे नाम ICardया CardComponent...

— ब्रूनो एलएम

SomeThingImpl implements SomeThingजितना अच्छा है SomeThing implements ISomeThing। यदि SomeThingएक अमूर्त है तो नामकरण होना चाहिए Concrete[Some]Thing implements SomeThing।

— स्टेनिस्लाव बेरकोव

जैसा कि @Guria द्वारा कहा गया है, मुझे लगता है कि टाइपस्क्रिप्ट हैंडबुक यह सब कहती है, हमें सिर्फ उदाहरणों पर ध्यान देना होगा और हम जानेंगे कि इसका उपयोग कैसे किया जाए।

— giovannipds

Answer 3

मुझे @ stanislav-berkov ओपी के सवाल का बहुत अच्छा जवाब मिला। मैं केवल अपने 2 सेंटों को जोड़कर साझा करूंगा, अंत में यह आपकी टीम / विभाग / कंपनी / जो भी एक आम समझ के लिए हो और अपने स्वयं के नियमों / दिशानिर्देशों का पालन करने के लिए सेट हो।

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

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

Answer 4

इंटरफ़ेस का प्रकार एक कार्यान्वयन विवरण है। कार्यान्वयन का विवरण एपीआई: एस में छिपा होना चाहिए। इसीलिए आपको बचना चाहिए I।

आप दोनों से बचना चाहिए prefix और suffix । ये दोनों गलत हैं:

• ICar
• CarInterface

एपीआई में एक सुंदर नाम दिखाई देने के लिए आपको क्या करना चाहिए और कार्यान्वयन में छिपा हुआ एक विस्तृत विवरण है। यही कारण है कि मैं प्रस्ताव:

• Car - एक इंटरफ़ेस जो एपीआई में उजागर होता है।
• CarImpl - उस एपीआई का एक कार्यान्वयन, जो उपभोक्ता से छिपा हुआ है।

Comments

वर्तमान में मैं इस संरचना का उपयोग करता हूं जो मेरी स्प्रिंगबूट पृष्ठभूमि से स्थापित किया गया था। तो टीएस में यह उचित माना जाता है? टीएस समुदाय में बहुत सी राय है जो बिना किसी निश्चित उत्तर के उचित है।

— अशुद्धता

Implप्रत्यय का उपयोग करने से पता चलेगा कि जो भी हो, उसका सभी पर दुष्प्रभाव होगा। यह सब आपको Iअंकल बॉब के साथ उपसर्ग के लिए उत्तेजित कर रहा है ।

— स्ज़ेपेपैन होलिज़ेव्स्की 16