Software Engineering — MCQ Practice

Hindi aur English dono mein practice karo — click karo answer check karne ke liye

📚 647 Questions 🌐 Hindi + English ✅ Free
भाषा / Language:
647 questions
241
EN + हिं Easy
GB What is the 'Law of Demeter' and what coupling problem does it address?
IN 'डेमेटर का नियम' क्या है और यह किस युग्मन समस्या का समाधान करता है?
A
Each class must have at most ten methods प्रत्येक कक्षा में अधिकतम दस विधियाँ होनी चाहिए
B
A method should only call methods of its own class, its parameters, objects it creates, or direct components — preventing 'train wreck' chaining that creates hidden long-range coupling एक विधि को केवल अपने स्वयं के वर्ग, उसके मापदंडों, उसके द्वारा बनाई गई वस्तुओं, या प्रत्यक्ष घटकों के तरीकों को कॉल करना चाहिए - 'ट्रेन मलबे' श्रृंखला को रोकना जो छिपी हुई लंबी दूरी की युग्मन बनाता है
C
Global variables are prohibited in object-oriented programs ऑब्जेक्ट-ओरिएंटेड प्रोग्राम में वैश्विक चर निषिद्ध हैं
D
All class attributes must be private with public getters and setters सभी वर्ग विशेषताएँ सार्वजनिक गेटर्स और सेटर्स के साथ निजी होनी चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Train wreck code like customer.getWallet().getCurrency().getSymbol() makes the caller dependent on the entire object graph's internal structure. The Law of Demeter limits coupling by requiring objects to communicate only with immediate neighbours, enforcing encapsulation.
व्याख्या (हिन्दी) ट्रेन व्रेक कोड जैसे customer.getWallet().getCurrency().getSymbol() कॉलर को संपूर्ण ऑब्जेक्ट ग्राफ़ की आंतरिक संरचना पर निर्भर बनाता है। डेमेटर का नियम वस्तुओं को केवल निकटतम पड़ोसियों के साथ संचार करने की आवश्यकता के द्वारा युग्मन को सीमित करता है, जिससे एनकैप्सुलेशन लागू होता है।
242
EN + हिं Medium
GB What distinguishes a 'layered architecture' from a 'hexagonal (ports and adapters) architecture'?
IN 'स्तरित आर्किटेक्चर' को 'हेक्सागोनल (पोर्ट और एडाप्टर) आर्किटेक्चर' से क्या अलग करता है?
A
Layered is for web applications; hexagonal is for desktop applications लेयर्ड वेब अनुप्रयोगों के लिए है; हेक्सागोनल डेस्कटॉप अनुप्रयोगों के लिए है
B
Layered enforces directional dependency flow (UI→Business→Data); hexagonal puts business logic at the centre with all external concerns as interchangeable adapters connecting through ports स्तरित दिशात्मक निर्भरता प्रवाह को लागू करता है (यूआई→व्यवसाय→डेटा); हेक्सागोनल बंदरगाहों के माध्यम से जुड़ने वाले विनिमेय एडेप्टर के रूप में सभी बाहरी चिंताओं के साथ व्यावसायिक तर्क को केंद्र में रखता है
C
Hexagonal has exactly six layers; layered can have any number हेक्सागोनल में ठीक छह परतें होती हैं; स्तरित में कोई भी संख्या हो सकती है
D
Both are identical; hexagonal is a newer name for layered दोनों एक जैसे हैं; हेक्सागोनल लेयर्ड का नया नाम है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) In layered architecture, business logic depends on the database — making database changes ripple upward. Alistair Cockburn's Hexagonal architecture isolates the domain model at the core; all I/O are adapters the domain doesn't depend on, enabling full testability without infrastructure.
व्याख्या (हिन्दी) स्तरित वास्तुकला में, व्यावसायिक तर्क डेटाबेस पर निर्भर करता है - जिससे डेटाबेस परिवर्तन ऊपर की ओर बढ़ते हैं। एलिस्टेयर कॉकबर्न की हेक्सागोनल वास्तुकला डोमेन मॉडल को मूल रूप से अलग करती है; सभी I/O एडेप्टर हैं जिन पर डोमेन निर्भर नहीं है, जो बुनियादी ढांचे के बिना पूर्ण परीक्षण योग्यता को सक्षम करते हैं।
243
EN + हिं Medium
GB What does 'Design by Contract' (DbC) entail and how does it differ from defensive programming?
IN 'डिज़ाइन बाय कॉन्ट्रैक्ट' (DbC) में क्या शामिल है और यह रक्षात्मक प्रोग्रामिंग से कैसे भिन्न है?
A
DbC is a legal framework for software licensing डीबीसी सॉफ्टवेयर लाइसेंसिंग के लिए एक कानूनी ढांचा है
B
DbC specifies formal preconditions, postconditions, and invariants — callers meet preconditions; method guarantees postconditions. Defensive programming checks all inputs regardless of responsibility, adding redundancy डीबीसी औपचारिक पूर्वशर्तें, पश्चशर्तें और अपरिवर्तनीयताएं निर्दिष्ट करता है - कॉल करने वाले पूर्वशर्तों को पूरा करते हैं; विधि पोस्टकंडिशन की गारंटी देती है। रक्षात्मक प्रोग्रामिंग जिम्मेदारी की परवाह किए बिना, अतिरेक जोड़ते हुए सभी इनपुट की जाँच करती है
C
DbC contracts are written by lawyers; defensive programming by developers डीबीसी अनुबंध वकीलों द्वारा लिखे जाते हैं; डेवलपर्स द्वारा रक्षात्मक प्रोग्रामिंग
D
Both are equivalent approaches with different terminology दोनों अलग-अलग शब्दावली के साथ समान दृष्टिकोण हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Bertrand Meyer's DbC creates a formal agreement: preconditions (caller's responsibility), postconditions (method's guarantee), invariants (always-true properties). DbC places blame clearly. Defensive programming checks everything everywhere — safer across trust boundaries but adds overhead and ambiguity.
व्याख्या (हिन्दी) बर्ट्रेंड मेयर का डीबीसी एक औपचारिक समझौता बनाता है: पूर्व शर्त (कॉलर की जिम्मेदारी), पोस्टकंडिशन (विधि की गारंटी), अपरिवर्तनीय (हमेशा-सही गुण)। डीबीसी स्पष्ट रूप से दोषारोपण करता है। रक्षात्मक प्रोग्रामिंग हर जगह हर चीज़ की जाँच करती है - विश्वास की सीमाओं के पार सुरक्षित लेकिन ओवरहेड और अस्पष्टता जोड़ती है।
244
EN + हिं Easy
GB What is the 'God Object' anti-pattern and what refactoring approach addresses it?
IN 'गॉड ऑब्जेक्ट' विरोधी पैटर्न क्या है और कौन सा रिफैक्टरिंग दृष्टिकोण इसे संबोधित करता है?
A
A highly reusable class handling all common utilities; should be kept and extended सभी सामान्य उपयोगिताओं को संभालने वाला एक अत्यधिक पुन: प्रयोज्य वर्ग; रखा जाना चाहिए और बढ़ाया जाना चाहिए
B
A class that knows too much or does too much — violating SRP and creating a hub of dependencies; addressed by extracting classes and redistributing responsibilities according to cohesion एक वर्ग जो बहुत अधिक जानता है या बहुत अधिक करता है - एसआरपी का उल्लंघन करता है और निर्भरता का केंद्र बनाता है; सामंजस्य के अनुसार वर्गों को निकालकर और जिम्मेदारियों को पुनर्वितरित करके संबोधित किया गया
C
The main entry point class of any application किसी भी एप्लिकेशन का मुख्य प्रवेश बिंदु वर्ग
D
Only a problem in procedural programming, not OOP केवल प्रक्रियात्मक प्रोग्रामिंग में एक समस्या है, OOP नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) God Objects accumulate as developers add functionality to an existing central class. Eventually it becomes monolithic and coupled to everything. Refactoring uses Extract Class to pull cohesive groups of responsibilities into dedicated classes.
व्याख्या (हिन्दी) जैसे ही डेवलपर्स मौजूदा केंद्रीय वर्ग में कार्यक्षमता जोड़ते हैं, गॉड ऑब्जेक्ट जमा हो जाते हैं। अंततः यह अखंड हो जाता है और हर चीज़ से जुड़ जाता है। रिफैक्टरिंग जिम्मेदारियों के एकजुट समूहों को समर्पित कक्षाओं में खींचने के लिए एक्सट्रैक्ट क्लास का उपयोग करता है।
245
EN + हिं Medium
GB What is the fundamental difference between 'composition' and 'inheritance' as reuse mechanisms in OOP?
IN OOP में पुन: उपयोग तंत्र के रूप में 'संरचना' और 'विरासत' के बीच मूलभूत अंतर क्या है?
A
Composition only with interfaces; inheritance requires abstract classes केवल इंटरफेस के साथ रचना; विरासत के लिए अमूर्त वर्गों की आवश्यकता होती है
B
Inheritance is static compile-time reuse creating 'is-a' relationships exposing parent internals; composition is dynamic runtime 'has-a' relationship that is more flexible, testable, and avoids the fragile base class problem वंशानुक्रम स्थैतिक संकलन-समय का पुन: उपयोग है जो मूल आंतरिक को उजागर करने वाले 'ए-ए' संबंध बनाता है; रचना गतिशील रनटाइम 'है-ए' संबंध है जो अधिक लचीला, परीक्षण योग्य है, और नाजुक बेस क्लास समस्या से बचाती है
C
Composition always produces faster code than inheritance कंपोज़िशन हमेशा इनहेरिटेंस की तुलना में तेज़ कोड उत्पन्न करता है
D
Both are equivalent; choice depends only on preference दोनों समतुल्य हैं; चुनाव केवल प्राथमिकता पर निर्भर करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) The 'fragile base class problem' shows inheritance's weakness: changing a parent class can break subclasses unexpectedly. GoF's 'favour composition over inheritance' recommends building objects from collaborating components, enabling runtime behaviour changes through dependency injection.
व्याख्या (हिन्दी) 'नाजुक आधार वर्ग समस्या' वंशानुक्रम की कमजोरी को दर्शाती है: मूल वर्ग को बदलने से उपवर्ग अप्रत्याशित रूप से टूट सकते हैं। GoF की 'विरासत पर अनुकूल संरचना' निर्भरता इंजेक्शन के माध्यम से रनटाइम व्यवहार परिवर्तन को सक्षम करने, सहयोगी घटकों से वस्तुओं के निर्माण की सिफारिश करती है।
246
EN + हिं Medium
GB What problem does the 'Observer' pattern solve and when does it introduce risk?
IN 'ऑब्जर्वर' पैटर्न किस समस्या का समाधान करता है और यह कब जोखिम उत्पन्न करता है?
A
Solves performance bottlenecks; introduces risk in single-user applications प्रदर्शन संबंधी बाधाओं को हल करता है; एकल-उपयोगकर्ता अनुप्रयोगों में जोखिम लाता है
B
Solves notifying multiple dependent objects when a subject changes without tight coupling; introduces risk of memory leaks (observers not unsubscribed), unexpected update cascades, and non-deterministic notification order जब कोई विषय बिना टाइट कपलिंग के बदलता है तो कई आश्रित वस्तुओं को सूचित करने का समाधान करता है; मेमोरी लीक (पर्यवेक्षकों ने सदस्यता समाप्त नहीं की है), अप्रत्याशित अपडेट कैस्केड और गैर-नियतात्मक अधिसूचना आदेश का जोखिम पेश किया है
C
Solves creating objects without specifying their exact classes वस्तुओं को उनकी सटीक कक्षाओं को निर्दिष्ट किए बिना बनाकर हल करता है
D
Introduces risk only in multithreaded environments; safe for single-threaded use केवल बहु-थ्रेडेड वातावरण में जोखिम का परिचय देता है; एकल-थ्रेडेड उपयोग के लिए सुरक्षित
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Observer (GoF) decouples subjects from observers using publish-subscribe. Risks: memory leaks when observers are not removed; update avalanches where one notification triggers uncontrollable chains; unexpected re-entry when an observer modifies the subject during notification.
व्याख्या (हिन्दी) ऑब्जर्वर (जीओएफ) पब्लिश-सब्सक्राइब का उपयोग करके विषयों को पर्यवेक्षकों से अलग करता है। जोखिम: जब पर्यवेक्षकों को नहीं हटाया जाता है तो मेमोरी लीक हो जाती है; अद्यतन हिमस्खलन जहां एक अधिसूचना अनियंत्रित श्रृंखलाओं को ट्रिगर करती है; जब कोई पर्यवेक्षक अधिसूचना के दौरान विषय को संशोधित करता है तो अप्रत्याशित पुनः प्रवेश।
247
EN + हिं Medium
GB What is 'separation of concerns' and how is it architecturally implemented in MVC?
IN 'चिंताओं का पृथक्करण' क्या है और इसे एमवीसी में वास्तुशिल्प रूप से कैसे लागू किया जाता है?
A
Different developers work on different parts simultaneously अलग-अलग डेवलपर अलग-अलग हिस्सों पर एक साथ काम करते हैं
B
Organising code so each module addresses a distinct aspect; MVC implements this by separating data/business logic (Model), presentation (View), and user interaction handling (Controller) कोड को व्यवस्थित करना ताकि प्रत्येक मॉड्यूल एक विशिष्ट पहलू को संबोधित करे; एमवीसी डेटा/बिजनेस लॉजिक (मॉडल), प्रेजेंटेशन (व्यू), और यूजर इंटरेक्शन हैंडलिंग (कंट्रोलर) को अलग करके इसे लागू करता है।
C
Separation of concerns only applies to database design चिंताओं का पृथक्करण केवल डेटाबेस डिज़ाइन पर लागू होता है
D
MVC implements separation by storing all state in Controller एमवीसी नियंत्रक में सभी स्थितियों को संग्रहीत करके पृथक्करण लागू करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Dijkstra's separation of concerns reduces complexity by preventing one concern from bleeding into another. MVC applies it to UI: the Model knows nothing about presentation; the View knows nothing about business rules; the Controller knows nothing about storage.
व्याख्या (हिन्दी) दिज्क्स्ट्रा की चिंताओं को अलग करने से एक चिंता को दूसरे में फैलने से रोककर जटिलता कम हो जाती है। एमवीसी इसे यूआई पर लागू करता है: मॉडल प्रस्तुति के बारे में कुछ नहीं जानता है; व्यू व्यावसायिक नियमों के बारे में कुछ नहीं जानता; नियंत्रक को भंडारण के बारे में कुछ नहीं पता है।
248
EN + हिं Medium
GB What is the 'magic number' anti-pattern in coding and how does it violate maintainability principles?
IN कोडिंग में 'मैजिक नंबर' एंटी-पैटर्न क्या है और यह कैसे रखरखाव सिद्धांतों का उल्लंघन करता है?
A
Randomly generated cryptographic keys embedded in code कोड में एम्बेडेड बेतरतीब ढंग से उत्पन्न क्रिप्टोग्राफ़िक कुंजियाँ
B
Unexplained numeric literals without context in code (e.g., 'if status == 4'); they make code intent opaque and require future maintainers to guess what the value represents कोड में संदर्भ के बिना अस्पष्ट संख्यात्मक अक्षर (उदाहरण के लिए, 'यदि स्थिति == 4'); वे कोड के इरादे को अपारदर्शी बनाते हैं और भावी अनुरक्षकों को यह अनुमान लगाने की आवश्यकता होती है कि मूल्य क्या दर्शाता है
C
Performance-critical constants that must remain unexplained to prevent reverse engineering प्रदर्शन-महत्वपूर्ण स्थिरांक जिन्हें रिवर्स इंजीनियरिंग को रोकने के लिए अस्पष्टीकृत रहना चाहिए
D
Only refers to values 0 and 1 in boolean contexts केवल बूलियन संदर्भों में मान 0 और 1 को संदर्भित करता है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) A magic number like 'if (retries == 3)' conveys no meaning. Naming it 'MAX_RETRY_ATTEMPTS = 3' documents intent, enables searching, and makes updates trivial. This is a fundamental readability and DRY violation.
व्याख्या (हिन्दी) 'if (पुनः प्रयास == 3)' जैसी जादुई संख्या का कोई मतलब नहीं है। इसे 'MAX_RETRY_ATTEMPTS = 3' नाम देने से दस्तावेज़ का उद्देश्य खोज करना संभव हो जाता है, और अपडेट को तुच्छ बना देता है। यह एक मौलिक पठनीयता और DRY उल्लंघन है।
249
EN + हिं Easy
GB What does the DRY principle prohibit and what is its violation called?
IN DRY सिद्धांत किस पर रोक लगाता है और इसका उल्लंघन क्या कहलाता है?
A
Writing comments in code; violations called 'over-commenting' कोड में टिप्पणियाँ लिखना; उल्लंघन जिसे 'अति-टिप्पणी' कहा जाता है
B
Having multiple representations of the same knowledge in the system; violations called 'WET' leading to inconsistent updates when one copy changes but others don't सिस्टम में एक ही ज्ञान के कई प्रतिनिधित्व होना; 'WET' नामक उल्लंघनों के कारण जब एक प्रति बदलती है लेकिन अन्य नहीं बदलती तो असंगत अद्यतन होते हैं
C
Using the same variable name in different scopes विभिन्न क्षेत्रों में एक ही चर नाम का उपयोग करना
D
Only about avoiding copy-pasted code blocks, not data duplication केवल कॉपी-पेस्ट किए गए कोड ब्लॉक से बचने के बारे में, डेटा डुप्लिकेशन के बारे में नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Hunt and Thomas defined DRY as: 'Every piece of knowledge must have a single, unambiguous, authoritative representation.' WET code creates synchronisation problems — if business rule X is encoded in three places and one changes, the system becomes inconsistent.
व्याख्या (हिन्दी) हंट और थॉमस ने DRY को इस प्रकार परिभाषित किया: 'ज्ञान के प्रत्येक टुकड़े में एक एकल, स्पष्ट, आधिकारिक प्रतिनिधित्व होना चाहिए।' WET कोड सिंक्रनाइज़ेशन समस्याएँ पैदा करता है - यदि व्यवसाय नियम X को तीन स्थानों पर एन्कोड किया गया है और एक में परिवर्तन होता है, तो सिस्टम असंगत हो जाता है।
250
EN + हिं Medium
GB What is the 'Boy Scout Rule' in software development and how does it relate to managing technical debt?
IN सॉफ्टवेयर विकास में 'बॉय स्काउट नियम' क्या है और यह तकनीकी ऋण प्रबंधन से कैसे संबंधित है?
A
Requires all developers to attend outdoor team-building activities monthly सभी डेवलपर्स को मासिक रूप से आउटडोर टीम-निर्माण गतिविधियों में भाग लेने की आवश्यकता है
B
'Leave the campground cleaner than you found it' applied to code: whenever you touch a module leave it slightly cleaner — incrementally paying down technical debt without dedicated refactoring sprints कोड पर लागू 'कैंपग्राउंड को जितना आपने पाया था उससे अधिक साफ-सुथरा छोड़ें': जब भी आप किसी मॉड्यूल को छूते हैं तो इसे थोड़ा साफ छोड़ दें - समर्पित रीफैक्टरिंग स्प्रिंट के बिना तकनीकी ऋण का क्रमिक रूप से भुगतान करना
C
Junior developers clean up code written by senior developers जूनियर डेवलपर्स वरिष्ठ डेवलपर्स द्वारा लिखे गए कोड को साफ़ करते हैं
D
A security practice requiring code review before deployment एक सुरक्षा अभ्यास जिसमें तैनाती से पहले कोड समीक्षा की आवश्यकता होती है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robert Martin's Boy Scout Rule addresses the reality that dedicated refactoring sprints are often deprioritised. By making incremental improvement routine — rename a confusing variable, extract a long method — teams prevent codebase degradation without special effort allocation.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन का बॉय स्काउट नियम इस वास्तविकता को संबोधित करता है कि समर्पित रिफैक्टरिंग स्प्रिंट को अक्सर प्राथमिकता नहीं दी जाती है। वृद्धिशील सुधार की दिनचर्या बनाकर - एक भ्रमित करने वाले चर का नाम बदलें, एक लंबी विधि निकालें - टीमें विशेष प्रयास आवंटन के बिना कोडबेस गिरावट को रोकती हैं।
251
EN + हिं Easy
GB What is 'defensive coding' and in what scenario is it specifically inappropriate?
IN 'रक्षात्मक कोडिंग' क्या है और किस परिदृश्य में यह विशेष रूप से अनुपयुक्त है?
A
Writing code that anticipates errors; inappropriate in cryptographic implementations where branches create timing side-channels त्रुटियों का पूर्वानुमान करने वाला कोड लिखना; क्रिप्टोग्राफ़िक कार्यान्वयन में अनुपयुक्त जहां शाखाएं टाइमिंग साइड-चैनल बनाती हैं
B
It is unnecessary when using statically typed languages स्थिर रूप से टाइप की गई भाषाओं का उपयोग करते समय यह अनावश्यक है
C
Inappropriate in any performance-critical system due to overhead ओवरहेड के कारण किसी भी प्रदर्शन-महत्वपूर्ण प्रणाली में अनुपयुक्त
D
Should be avoided in test code to keep tests simple परीक्षणों को सरल बनाए रखने के लिए परीक्षण कोड से बचना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Defensive coding proactively validates inputs and handles error conditions. In cryptographic code, defensive branches can create timing variations measurable by attackers — timing side-channel attacks exploit different execution times depending on secret values. Constant-time algorithms deliberately avoid conditional branches.
व्याख्या (हिन्दी) रक्षात्मक कोडिंग सक्रिय रूप से इनपुट को मान्य करती है और त्रुटि स्थितियों को संभालती है। क्रिप्टोग्राफ़िक कोड में, रक्षात्मक शाखाएं हमलावरों द्वारा मापने योग्य समय भिन्नताएं बना सकती हैं - टाइमिंग साइड-चैनल हमले गुप्त मूल्यों के आधार पर विभिन्न निष्पादन समय का फायदा उठाते हैं। लगातार-समय एल्गोरिदम जानबूझकर सशर्त शाखाओं से बचते हैं।
252
EN + हिं Medium
GB What is the key difference between a 'code smell' and a 'bug' and why do code smells matter?
IN 'कोड गंध' और 'बग' के बीच मुख्य अंतर क्या है और कोड गंध क्यों मायने रखती है?
A
Code smells are compiler warnings; bugs are runtime errors कोड गंध संकलक चेतावनियाँ हैं; बग रनटाइम त्रुटियाँ हैं
B
A bug is a functional defect causing incorrect behaviour; a code smell is a structural indicator of potential design problems that may not currently fail but increase likelihood of future bugs and raise maintenance costs बग एक कार्यात्मक दोष है जो गलत व्यवहार का कारण बनता है; कोड गंध संभावित डिज़ाइन समस्याओं का एक संरचनात्मक संकेतक है जो वर्तमान में विफल नहीं हो सकती है लेकिन भविष्य में बग की संभावना बढ़ जाती है और रखरखाव लागत बढ़ जाती है
C
Code smells only relevant in Python and JavaScript due to dynamic typing गतिशील टाइपिंग के कारण कोड केवल पायथन और जावास्क्रिप्ट में ही प्रासंगिक लगता है
D
Code smells and bugs are synonymous in code review कोड समीक्षा में कोड गंध और बग पर्यायवाची हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Fowler's code smells (long methods, large classes, duplicate code) are structural warning signs suggesting refactoring is needed. They don't cause immediate failures but signal design decay making future modification error-prone.
व्याख्या (हिन्दी) फाउलर के कोड की गंध (लंबी विधियां, बड़ी कक्षाएं, डुप्लिकेट कोड) संरचनात्मक चेतावनी संकेत हैं जो सुझाव देते हैं कि रीफैक्टरिंग की आवश्यकता है। वे तत्काल विफलताओं का कारण नहीं बनते हैं लेकिन सिग्नल डिज़ाइन ख़राब हो जाते हैं जिससे भविष्य में संशोधन में त्रुटि-प्रवण हो जाता है।
253
EN + हिं Easy
GB What is the correct interpretation of 'responsibility' in the Single Responsibility Principle (SRP)?
IN एकल उत्तरदायित्व सिद्धांत (एसआरपी) में 'जिम्मेदारी' की सही व्याख्या क्या है?
A
A class should have only one method एक कक्षा में केवल एक ही विधि होनी चाहिए
B
A class should have only one reason to change — where 'reason to change' corresponds to a stakeholder group or business concern, not merely a functional category एक वर्ग के पास परिवर्तन का केवल एक ही कारण होना चाहिए - जहां 'परिवर्तन का कारण' एक हितधारक समूह या व्यावसायिक चिंता से मेल खाता है, न कि केवल एक कार्यात्मक श्रेणी से।
C
Each developer is responsible for maintaining exactly one class प्रत्येक डेवलपर ठीक एक वर्ग को बनाए रखने के लिए जिम्मेदार है
D
Only applicable to functional programming, not OOP केवल कार्यात्मक प्रोग्रामिंग पर लागू, OOP पर नहीं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Robert Martin clarified that 'responsibility' means 'a reason to change' corresponding to a specific stakeholder or user group. A class generating a report AND emailing it has two reasons to change — finance team wanting different content, and IT changing email infrastructure. These are separate responsibilities.
व्याख्या (हिन्दी) रॉबर्ट मार्टिन ने स्पष्ट किया कि 'जिम्मेदारी' का अर्थ किसी विशिष्ट हितधारक या उपयोगकर्ता समूह के अनुरूप 'परिवर्तन का एक कारण' है। एक वर्ग जो रिपोर्ट तैयार करता है और उसे ईमेल करता है, उसमें बदलाव के दो कारण होते हैं - वित्त टीम अलग सामग्री चाहती है, और आईटी ईमेल बुनियादी ढांचे को बदल रही है। ये अलग जिम्मेदारियां हैं.
254
EN + हिं Medium
GB What specific problem does the 'assert' statement solve and why should it NOT be used for input validation?
IN 'जोर' कथन किस विशिष्ट समस्या का समाधान करता है और इसका उपयोग इनपुट सत्यापन के लिए क्यों नहीं किया जाना चाहिए?
A
Used to improve performance by eliminating runtime type checks रनटाइम प्रकार की जांच को समाप्त करके प्रदर्शन में सुधार करने के लिए उपयोग किया जाता है
B
Asserts document and enforce invariants about program's internal state; should not validate external inputs because assertions are typically disabled in production builds allowing invalid inputs to pass unchecked प्रोग्राम की आंतरिक स्थिति के बारे में दस्तावेज़ पर जोर देता है और अपरिवर्तनीयताओं को लागू करता है; बाहरी इनपुट को मान्य नहीं करना चाहिए क्योंकि उत्पादन बिल्ड में दावे आम तौर पर अक्षम होते हैं जिससे अमान्य इनपुट अनियंत्रित हो जाते हैं
C
Assert statements equivalent to unit tests and can replace them यूनिट परीक्षणों के समतुल्य कथनों पर जोर दें और उन्हें प्रतिस्थापित कर सकते हैं
D
Asserts should only be used in languages without exception handling दावे का उपयोग केवल अपवाद प्रबंधन के बिना भाषाओं में किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Assertions check internal assumptions that should never be false if code is correct. For user-supplied data, use explicit validation with informative exceptions because: assertions may be compiled out, they produce poor user-facing messages, and they conflate internal logic errors with external input errors.
व्याख्या (हिन्दी) दावे आंतरिक धारणाओं की जाँच करते हैं जो कोड सही होने पर कभी भी गलत नहीं होने चाहिए। उपयोगकर्ता द्वारा प्रदत्त डेटा के लिए, सूचनात्मक अपवादों के साथ स्पष्ट सत्यापन का उपयोग करें क्योंकि: दावे संकलित किए जा सकते हैं, वे खराब उपयोगकर्ता-सामना वाले संदेश उत्पन्न करते हैं, और वे बाहरी इनपुट त्रुटियों के साथ आंतरिक तर्क त्रुटियों को मिलाते हैं।
255
EN + हिं Medium
GB What is 'cyclomatic complexity', how is it calculated, and what threshold typically indicates need for refactoring?
IN 'साइक्लोमैटिक जटिलता' क्या है, इसकी गणना कैसे की जाती है, और कौन सी सीमा आम तौर पर रिफैक्टरिंग की आवश्यकता को इंगित करती है?
A
Ratio of comments to code lines; above 0.5 needs refactoring कोड पंक्तियों पर टिप्पणियों का अनुपात; 0.5 से ऊपर रिफैक्टरिंग की आवश्यकता है
B
McCabe's metric counting linearly independent paths: M = E - N + 2P; complexity above 10 indicates code difficult to test and maintain — should be refactored into smaller units मैककेब की मीट्रिक गणना रैखिक रूप से स्वतंत्र पथ: एम = ई - एन + 2पी; 10 से ऊपर की जटिलता इंगित करती है कि कोड का परीक्षण और रखरखाव करना मुश्किल है - इसे छोटी इकाइयों में दोबारा तैयार किया जाना चाहिए
C
Measures total number of variables declared in a function किसी फ़ंक्शन में घोषित वेरिएबल्स की कुल संख्या को मापता है
D
Above 100 requires refactoring; below 100 always acceptable 100 से ऊपर रिफैक्टरिंग की आवश्यकता होती है; 100 से नीचे सदैव स्वीकार्य
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) McCabe's cyclomatic complexity: M = E (edges) - N (nodes) + 2P (components). Practically equals 1 plus number of decision points. McCabe recommended M ≤ 10; above 10, code becomes too complex to reliably test all paths. Studies show strong correlation with defect density.
व्याख्या (हिन्दी) मैककेबे की चक्रीय जटिलता: एम = ई (किनारे) - एन (नोड्स) + 2पी (घटक)। व्यावहारिक रूप से निर्णय बिंदुओं की संख्या 1 से अधिक के बराबर होती है। McCabe recommended M ≤ 10; 10 से ऊपर, सभी पथों का विश्वसनीय परीक्षण करने के लिए कोड बहुत जटिल हो जाता है। अध्ययन दोष घनत्व के साथ मजबूत संबंध दिखाते हैं।
241–255 of 647