ठोस सिद्धांत और कोड संरचना

Question

हाल ही में एक नौकरी के साक्षात्कार में, मैं SOLID के बारे में एक सवाल का जवाब नहीं दे सका - विभिन्न सिद्धांतों के मूल अर्थ प्रदान करने से परे। यह वास्तव में मुझे परेशान करता है। मैंने कुछ दिनों के आसपास खुदाई करने लायक काम किया है और एक संतोषजनक सारांश के साथ आना अभी बाकी है।

साक्षात्कार का प्रश्न था:

यदि आप एक। नेट परियोजना को देखते हैं जो मैंने आपको ठोस सिद्धांतों का पालन करने के लिए कड़ाई से कहा था, तो आप परियोजना और कोड संरचना के संदर्भ में क्या देखने की उम्मीद करेंगे?

मैं थोड़ा इधर-उधर हो गया, वास्तव में इस सवाल का जवाब नहीं दिया, और फिर बमबारी की।

मैं इस सवाल को बेहतर तरीके से कैसे संभाल सकता था?

Comments

मैं सोच रहा था कि SOLID के लिए विकी पृष्ठ

— B whatови

एक्स्टेंसिबल एसेन्स बिल्डिंग ब्लॉक्स।

— 20

ऑब्जेक्ट ओरिएंटेड डिज़ाइन के SOLID सिद्धांतों का पालन करने से, आपकी कक्षाएं स्वाभाविक रूप से छोटे, अच्छी तरह से फैक्टेड और आसानी से परीक्षण किए जाएंगे। स्रोत: docs.asp.net/en/latest/fundamentals/…

— AfterTrueSleep

Answer 1

एस = एकल जिम्मेदारी सिद्धांत

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

यदि आपने कोड की हजार लाइनों के साथ विशाल प्रबंधक कक्षाएं देखीं, तो यह एक संकेत होगा कि एकल जिम्मेदारी का पालन नहीं किया जा रहा है।

ओ = खुला / बंद सिद्धांत

यह मूल रूप से विचार है कि नई कार्यक्षमता को नई कक्षाओं के माध्यम से जोड़ा जाना चाहिए, जिनका मौजूदा कार्यक्षमता के संशोधन / आवश्यकता पर न्यूनतम प्रभाव पड़ता है।

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

एल = लिस्कोव प्रतिस्थापन सिद्धांत

यह उप-प्रकारों को उनके मूल प्रकार के रूप में व्यवहार करने की क्षमता के साथ करना है। यह सी # में बॉक्स से बाहर आता है यदि आप एक उचित विरासत वाली वस्तु पदानुक्रम को लागू कर रहे हैं।

मैं कोड को सामान्य वस्तुओं को उनके आधार प्रकार के रूप में देखने की उम्मीद करता हूं और आधार / अमूर्त वर्गों पर कॉल करने के तरीकों को त्वरित करने और उप-प्रकारों पर काम करने के बजाय खुद को देखता हूं।

I = इंटरफ़ेस अलगाव सिद्धांत

यह एसआरपी के समान है। असल में, आप कार्यक्षमता के छोटे उपसमुच्चय को परिभाषित करते हैं और आपके सिस्टम को डिकूप्टेड रखने के लिए उन लोगों के साथ काम करते हैं (जैसे FileManagerफ़ाइल I / O के साथ काम करने की एकल जिम्मेदारी हो सकती है, लेकिन यह एक को लागू कर सकता है IFileReaderऔर IFileWriterजिसमें पढ़ने के लिए विशिष्ट विधि परिभाषाएं शामिल हैं। और फाइलों का लेखन)।

डी = निर्भरता उलटा सिद्धांत।

फिर से यह एक प्रणाली को डिकोड किए जाने से संबंधित है। शायद आप एक .NET डिपेंडेंसी इंजेक्शन लाइब्रेरी के उपयोग की तलाश में होंगे, जैसे कि Unityया इस तरह के Ninjectएक ServiceLocator सिस्टम के समाधान में उपयोग किया जा रहा है AutoFacServiceLocator।

Comments

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

— जिमी हॉफ

@JimmyHoffa मुख्य कारणों में से एक है जो मैं कोड कॉन्ट्रैक्ट्स का उपयोग करने पर जोर देता हूं; ठेके को डिजाइन करने की सोची गई प्रक्रिया से गुजरने से लोगों को उस बुरी आदत से बाहर निकालने में बहुत मदद मिलती है।

— एंडी

मुझे "एलएसपी सी # में बॉक्स से बाहर नहीं आता है" और डीआईपी की निर्भरता इंजेक्शन अभ्यास के बराबर है।

— व्यंग्यात्मक

+1 लेकिन निर्भरता उलटा <> निर्भरता इंजेक्शन। वे एक साथ अच्छी तरह से खेलते हैं, लेकिन निर्भरता उलटा सिर्फ निर्भरता इंजेक्शन की तुलना में बहुत अधिक है। संदर्भ: जंगली में डीआईपी

— मार्जन वेनेमा

@ और: जो भी मदद करता है वह इकाई परीक्षण है, जिसके खिलाफ इंटरफेस पर परिभाषित किया गया है, जिसके तहत सभी कार्यान्वयनकर्ता (किसी भी वर्ग / जो तत्काल / कर सकते हैं) का परीक्षण किया जाता है।

— मार्जन वेनेमा

Answer 2

सभी स्थानों पर निर्भरता इंजेक्शन के साथ बहुत सारे छोटे वर्ग और इंटरफेस। संभवतः एक बड़ी परियोजना में आप उन सभी छोटी वस्तुओं के जीवनकाल के निर्माण और प्रबंधन में मदद करने के लिए एक IoC ढांचे का उपयोग करेंगे। Https://stackoverflow.com/questions/21288/which-net-d dependency-injection-frameworks-are-worth-looking-into देखें

ध्यान दें कि एक बड़ी .NET प्रॉजेक्ट जो स्ट्रॉन्ली केवल SOLID सिद्धांतों का पालन करता है, जरूरी नहीं कि हर किसी के साथ काम करने के लिए एक अच्छा कोडबेस हो। साक्षात्कारकर्ता कौन था, इस पर निर्भर करते हुए, वह / वह शायद आपको दिखाना चाहते थे कि आप समझते हैं कि SOLID का क्या मतलब है और / या जाँच करें कि आप डिजाइन सिद्धांतों का पालन कैसे करते हैं।

आप देखते हैं, ठोस होने के लिए, आपको अनुसरण करने की आवश्यकता है:

एस जिम्मेदारी जिम्मेदारी सिद्धांत, तो आप कई छोटे वर्गों उनमें से प्रत्येक केवल एक ही काम कर रहा होगा

O पेन-बंद सिद्धांत, जो .NET में आमतौर पर निर्भरता इंजेक्शन के साथ लागू किया जाता है, जिसे नीचे I और D की भी आवश्यकता होती है ...

एल iskov प्रतिस्थापन सिद्धांत सी # एक लाइनर के साथ समझाने में असंभव है। सौभाग्य से इसे संबोधित करने वाले अन्य प्रश्न हैं, उदाहरण के लिए https://stackoverflow.com/questions/4428725/can-you-explain-liskov-substoration-principle-with-a-good-c-sharp-example

I nterface पृथक्करण सिद्धांत ओपन-क्लोज्ड सिद्धांत के साथ मिलकर काम करता है। अगर इसका अक्षरशः पालन किया जाता है तो इसका मतलब होगा कि बहुत बड़ी संख्या में छोटे इंटरफेस को तरजीह देना, बल्कि कुछ "बड़े" इंटरफेस को

डी एपेंडेंसी उलटा सिद्धांत उच्च-स्तरीय कक्षाएं निम्न-स्तरीय कक्षाओं पर निर्भर नहीं होनी चाहिए, दोनों को अमूर्तता पर निर्भर होना चाहिए।

Comments

SRP का मतलब यह नहीं है कि "केवल एक काम करो।"

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

Answer 3

कुछ बुनियादी चीजें जो मैं एक दुकान के कोडबेस में देखना चाहता हूं, जो अपने दैनिक कार्य में SOLID की जासूसी करता है:

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

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

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

• इंटरफेस और एबीसी के बहुत सारे - डीआईपी को जरूरी है कि अमूर्तताएं मौजूद हों, और आईएसपी उन्हें संकीर्ण रूप से बिखेरने के लिए प्रोत्साहित करता है। इसलिए, इंटरफेस और अमूर्त आधार कक्षाएं नियम हैं, और आपको अपने कोडबेस की साझा निर्भरता कार्यक्षमता को कवर करने के लिए उनमें से बहुत कुछ की आवश्यकता होगी। जबकि ठोस SOLID को हर चीज को इंजेक्ट करने की आवश्यकता होती है , यह स्पष्ट है कि आपको कहीं और बनाना होगा, और इसलिए यदि GUI फॉर्म केवल एक माता-पिता के बच्चे के रूप में बनाया गया है, तो उन्होंने कहा कि माता-पिता के बारे में कुछ कार्रवाई करने से, मेरे पास बच्चे के फॉर्म को प्राप्त करने के लिए कोई योग्यता नहीं है। सीधे माता पिता के भीतर कोड से। मैं आमतौर पर उस कोड को अपनी विधि बनाता हूं, इसलिए यदि उसी रूप की दो क्रियाओं ने कभी खिड़की खोली है, तो मैं सिर्फ विधि को कॉल करता हूं।
• कई परियोजनाएँ - इस सब का बिंदु परिवर्तन के दायरे को सीमित करना है। परिवर्तन में पुनर्संयोजन (अब और अपेक्षाकृत तुच्छ अभ्यास, लेकिन फिर भी कई प्रोसेसर में महत्वपूर्ण है- और बैंडविड्थ-महत्वपूर्ण संचालन, जैसे मोबाइल वातावरण में अपडेट को तैनात करना) शामिल हैं। यदि किसी प्रोजेक्ट की एक फाइल को फिर से बनाया जाना है, तो सभी फाइलें होती हैं। इसका मतलब है कि यदि आप समान पुस्तकालयों में उनके कार्यान्वयन के रूप में इंटरफेस रखते हैं, तो आप बिंदु को याद कर रहे हैं; यदि आप इंटरफ़ेस के कार्यान्वयन को बदलते हैं, तो आपको सभी उपयोगों को फिर से प्राप्त करना होगा क्योंकि आप इंटरफ़ेस परिभाषा को फिर से जोड़ रहे होंगे, जिसके परिणामस्वरूप usages की आवश्यकता होगी ताकि परिणामी बाइनरी में एक नए स्थान को इंगित किया जा सके। इसलिए, इंटरफेस को usages से अलग रखना और कार्यान्वयन, जबकि इसके अतिरिक्त उपयोग के सामान्य क्षेत्र द्वारा उन्हें अलग करना, एक विशिष्ट सर्वोत्तम अभ्यास है।
• "गैंग ऑफ़ फोर" शब्दावली पर ध्यान दिया गया - 1994 की पुस्तक डिज़ाइन पैटर्न में पहचाने गए डिज़ाइन पैटर्न काटने के आकार, मॉड्यूलर कोड डिज़ाइन पर जोर देते हैं, जिसे SOLID बनाना चाहता है। उदाहरण के लिए, डिपेंडेंसी इनवर्सन प्रिंसिपल और ओपन / क्लोज्ड प्रिंसिपल, उस पुस्तक के अधिकांश चिन्हित पैटर्न के दिल में हैं। जैसे, मैं एक ऐसी दुकान की उम्मीद करूंगा, जो ठोस सिद्धांतों का दृढ़ता से पालन करती है, चार की किताब की गैंग में शब्दावली को भी गले लगाती है, और उन पंक्तियों के अनुसार उनके फ़ंक्शन के अनुसार नाम कक्षाएं, जैसे कि "एबकफैक्ट्री", "एक्सज़ेरोसॉजिटरी", "डेफटॉक्सएक्सजेड एडेप्टर" "," A1Command "आदि।
• एक सामान्य रिपॉजिटरी - आईएसपी, डीआईपी और एसआरपी के साथ आमतौर पर समझा जाने वाला, रिपॉजिटरी एसओएलडी डिजाइन में लगभग सर्वव्यापी है, क्योंकि यह कोड को उपभोग करने के लिए एक जटिल तरीके से पुनर्प्राप्ति / दृढ़ता तंत्र के विशिष्ट ज्ञान की आवश्यकता के बिना एक सार तरीके से पूछता है। यह उस कोड को डालता है जो DAO पैटर्न के विपरीत एक स्थान पर करता है (जिसमें यदि आपके पास, उदाहरण के लिए, एक चालान डेटा वर्ग है, तो आपके पास एक चालान कार्ड भी होगा जो उस प्रकार की हाइड्रेटेड वस्तुओं का उत्पादन करता है, और इसी तरह से इसके लिए भी सभी डेटा ऑब्जेक्ट / कोडबेस / स्कीमा में टेबल)।
• एक IoC कंटेनर - मैं इसे जोड़ने में संकोच करता हूं, क्योंकि मैं वास्तव में अपने निर्भरता इंजेक्शन के बहुमत करने के लिए एक IoC ढांचे का उपयोग नहीं करता हूं। यह जल्दी से कंटेनर में सब कुछ फेंकने का एक ईश्वर वस्तु विरोधी पैटर्न बन जाता है, इसे हिलाता है और खड़ी-हाइड्रेटेड निर्भरता को बाहर निकालता है जो आपको एक इंजेक्टेड फैक्ट्री विधि के माध्यम से चाहिए। बहुत अच्छा लगता है, जब तक आप महसूस नहीं करते कि संरचना बहुत अखंड हो जाती है, और पंजीकरण जानकारी के साथ परियोजना, अगर "धाराप्रवाह", अब आपके समाधान में सब कुछ के बारे में सब कुछ जानना होगा। जो कि बदलने के बहुत से कारण है। यदि यह धाराप्रवाह नहीं है (कॉन्फिग फाइलों का उपयोग करते हुए देर से-सही पंजीकरण), तो आपके प्रोग्राम का एक प्रमुख टुकड़ा "जादू के तार" पर निर्भर करता है, एक पूरी तरह से अलग हो सकता है।

Comments

डाउनवोट्स क्यों?

— कीथ्स

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

— Crowie

Answer 4

जॉन स्कीट की चर्चा से उन्हें विचलित करें कि SOLID में 'O' कैसे "अनहेल्दी और खराब समझ" है और उन्हें एलिस्टेयर कॉकबर्न की "संरक्षित विविधता" और जोश बलोच के "वंशानुक्रम के लिए डिजाइन, या इसे निषिद्ध करने" के बारे में बात करें।

स्कीट के लेख का संक्षिप्त सारांश (हालांकि मैं मूल ब्लॉग पोस्ट को पढ़े बिना उसका नाम छोड़ने की सलाह नहीं दूंगा!)

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

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

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

Answer 5

संभवत: कई तरीके हैं, जिन्हें अलग-अलग समय के साथ उत्तर दिया जा सकता है। हालांकि, मुझे लगता है कि यह "क्या आप जानते हैं कि SOLID का मतलब क्या है?" तो इस सवाल का जवाब शायद सिर्फ एक अंक देने और एक परियोजना के संदर्भ में समझाने के लिए उबलता है।

तो, आप निम्नलिखित देखने की उम्मीद करते हैं:

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

Answer 6

यह एक उत्कृष्ट प्रश्न है, हालांकि मुझे लगता है कि यह एक कठिन साक्षात्कार प्रश्न है।

ठोस सिद्धांत वास्तव में कक्षाओं और इंटरफेस को नियंत्रित करते हैं और वे एक दूसरे से कैसे संबंधित हैं।

यह सवाल वास्तव में एक है कि फ़ाइलों के साथ अधिक करना है और जरूरी नहीं कि कक्षाएं।

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

रॉबर्ट मार्टिन इस विषय पर चर्चा करते हैं सी ++ के डिजाइनिंग ऑब्जेक्टेड ओरिएंटेड सी ++ एप्लीकेशन में बूच विधि (कोशिशन, क्लोजर और रियूजेबिलिटी पर सेक्शन देखें) और क्लीन कोड में ।

Comments

.NET कोडर्स IME आमतौर पर "फाइल प्रति 1 वर्ग" नियम का पालन करता है, और दर्पण फ़ोल्डर / नामस्थान संरचनाएं भी; विज़ुअल स्टूडियो IDE दोनों प्रथाओं को प्रोत्साहित करता है, और ReSharper जैसे विभिन्न प्लगइन्स उन्हें लागू कर सकते हैं। इसलिए, मैं एक परियोजना / फ़ाइल संरचना को देखने के लिए कक्षा / इंटरफ़ेस संरचना को प्रतिबिंबित करना चाहूंगा।

— कीथ्स