2296

EN + हिं Easy

GB What is the 'open-closed principle' (OCP) and what design mechanism commonly implements it?

IN 'खुला-बंद सिद्धांत' (ओसीपी) क्या है और कौन सा डिज़ाइन तंत्र आमतौर पर इसे लागू करता है?

A

OCP states that software should be open to all developers for modification at any time OCP का कहना है कि सॉफ़्टवेयर किसी भी समय संशोधन के लिए सभी डेवलपर्स के लिए खुला होना चाहिए

B

OCP (Bertrand Meyer/Martin): software entities should be open for extension but closed for modification — commonly implemented through abstract base classes/interfaces where new behaviours are added by creating new implementing classes rather than modifying existing ones ओसीपी (बर्ट्रेंड मेयर/मार्टिन): सॉफ्टवेयर इकाइयां विस्तार के लिए खुली होनी चाहिए लेकिन संशोधन के लिए बंद होनी चाहिए - आमतौर पर अमूर्त आधार वर्गों/इंटरफ़ेस के माध्यम से कार्यान्वित की जाती हैं जहां मौजूदा को संशोधित करने के बजाय नए कार्यान्वयन वर्ग बनाकर नए व्यवहार जोड़े जाते हैं

C

OCP prohibits the use of inheritance and requires composition-only design OCP इनहेरिटेंस के उपयोग पर प्रतिबंध लगाता है और केवल-रचना डिज़ाइन की आवश्यकता होती है

D

OCP requires that once a class is deployed to production, no changes are ever permitted OCP के लिए आवश्यक है कि एक बार एक वर्ग को उत्पादन में तैनात करने के बाद, किसी भी बदलाव की अनुमति नहीं दी जाए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Classic OCP violation: adding a new payment type requires modifying the PaymentProcessor class (adding an if-else branch). OCP solution: PaymentProcessor depends on a PaymentMethod interface; adding PayPal means creating a PayPalPaymentMethod class without touching PaymentProcessor. Strategy and Template Method patterns are canonical OCP implementations — new strategies extend the design without modifying the stable core.

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

2297

EN + हिं Easy

GB What is the 'interface segregation principle' (ISP) and what problem in large interfaces does it solve?

IN 'इंटरफ़ेस पृथक्करण सिद्धांत' (आईएसपी) क्या है और यह बड़े इंटरफ़ेस में किस समस्या का समाधान करता है?

A

ISP requires that all interfaces must be public and accessible from any class in the system आईएसपी के लिए आवश्यक है कि सभी इंटरफेस सार्वजनिक हों और सिस्टम में किसी भी वर्ग से पहुंच योग्य हों

B

ISP states that clients should not be forced to depend on methods they don't use — large fat interfaces force implementing classes to provide empty or throw-not-implemented implementations, indicating a design smell that should be split into focused interfaces आईएसपी का कहना है कि ग्राहकों को उन तरीकों पर निर्भर रहने के लिए मजबूर नहीं किया जाना चाहिए जिनका वे उपयोग नहीं करते हैं - बड़े मोटे इंटरफेस कार्यान्वयन कक्षाओं को खाली या थ्रो-न-कार्यान्वित कार्यान्वयन प्रदान करने के लिए मजबूर करते हैं, जो एक डिजाइन गंध का संकेत देता है जिसे केंद्रित इंटरफेस में विभाजित किया जाना चाहिए

C

ISP only applies to abstract factory patterns and similar creational patterns आईएसपी केवल अमूर्त फ़ैक्टरी पैटर्न और समान रचनात्मक पैटर्न पर लागू होता है

D

ISP is identical to OCP and was added to SOLID as a duplicate for clarity ISP OCP के समान है और स्पष्टता के लिए इसे SOLID में डुप्लिकेट के रूप में जोड़ा गया था

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A 'fat' interface (IWorker with methods Work(), Eat(), Sleep()) forces a RobotWorker to implement Eat() and Sleep() with throws or empty bodies — a Liskov violation signal. ISP splits it: IWorkable (Work()), IFeedable (Eat()), IRestable (Sleep()). Human implements all three; Robot implements only IWorkable. This prevents implementing classes from being saddled with inappropriate responsibilities.

व्याख्या (हिन्दी) एक 'वसा' इंटरफ़ेस (कार्य(), ईट(), स्लीप() तरीकों के साथ IWorker) एक रोबोटवर्कर को थ्रो या खाली निकायों के साथ ईट() और स्लीप() को लागू करने के लिए मजबूर करता है - एक लिस्कोव उल्लंघन संकेत। ISP इसे विभाजित करता है: IWorkable (कार्य()), IFeedable (खाओ()), IRestable (नींद())। मानव तीनों को क्रियान्वित करता है; रोबोट केवल IWorkable को कार्यान्वित करता है। यह कार्यान्वयन कक्षाओं को अनुचित जिम्मेदारियों से बोझिल होने से रोकता है।

2298

EN + हिं Easy

GB What is 'design pattern' versus 'architectural pattern', and what is a concrete example of each?

IN 'डिज़ाइन पैटर्न' बनाम 'वास्तुशिल्प पैटर्न' क्या है, और प्रत्येक का एक ठोस उदाहरण क्या है?

A

Design patterns apply to databases; architectural patterns apply to application code डिज़ाइन पैटर्न डेटाबेस पर लागू होते हैं; आर्किटेक्चरल पैटर्न एप्लिकेशन कोड पर लागू होते हैं

B

Architectural patterns describe system-level structure (Microservices, MVC, Event-driven, Layered); design patterns describe local object-level solutions (Singleton, Observer, Factory) — architectural patterns have system-wide impact; design patterns are applied within individual components वास्तुशिल्प पैटर्न सिस्टम-स्तरीय संरचना (माइक्रोसर्विसेज, एमवीसी, इवेंट-संचालित, स्तरित) का वर्णन करते हैं; डिज़ाइन पैटर्न स्थानीय ऑब्जेक्ट-स्तरीय समाधानों (सिंगलटन, ऑब्जर्वर, फ़ैक्टरी) का वर्णन करते हैं - वास्तुशिल्प पैटर्न का सिस्टम-व्यापी प्रभाव होता है; डिज़ाइन पैटर्न व्यक्तिगत घटकों के भीतर लागू किए जाते हैं

C

Both terms are synonymous; the distinction is merely academic दोनों शब्द पर्यायवाची हैं; यह भेद केवल अकादमिक है

D

Design patterns are proprietary to GoF authors; architectural patterns are in the public domain डिज़ाइन पैटर्न GoF लेखकों के स्वामित्व में हैं; वास्तुशिल्प पैटर्न सार्वजनिक डोमेन में हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) GoF's 23 patterns (Observer, Factory, Strategy) solve recurring object-collaboration problems within a component; they are implementation-level tools. Architectural patterns (Fowler's PoEAA, Buschmann's POSA) describe system organisation: Microservices determines how to decompose a system across process boundaries; this is not a design detail but a fundamental structural commitment with system-wide implications for deployment, scaling, and team organisation.

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

2299

EN + हिं Easy

GB What is the 'decorator pattern' and what does it enable that inheritance cannot provide?

IN 'डेकोरेटर पैटर्न' क्या है और यह ऐसा क्या सक्षम बनाता है जो विरासत प्रदान नहीं कर सकती?

A

Decorator pattern is a syntax construct in Python for modifying function behaviour at class definition time क्लास परिभाषा समय पर फ़ंक्शन व्यवहार को संशोधित करने के लिए डेकोरेटर पैटर्न पायथन में एक वाक्यविन्यास निर्माण है

B

Decorator pattern wraps an object to add responsibilities dynamically at runtime — enabling combinations of behaviours (Logging + Caching + Authentication) without the combinatorial explosion that inheritance requires (LoggingCachingAuthWrapper vs AuthCachingWrapper etc.) डेकोरेटर पैटर्न रनटाइम पर जिम्मेदारियों को गतिशील रूप से जोड़ने के लिए एक ऑब्जेक्ट को लपेटता है - व्यवहार के संयोजन को सक्षम करता है (लॉगिंग + कैशिंग + प्रमाणीकरण) बिना किसी संयोजन विस्फोट के जिसके लिए विरासत की आवश्यकता होती है (लॉगिंग कैशिंगऑथवैपर बनाम ऑथकैचिंगरैपर आदि)

C

Decorator pattern is identical to the Proxy pattern and the terms can be used interchangeably डेकोरेटर पैटर्न प्रॉक्सी पैटर्न के समान है और शब्दों का उपयोग परस्पर उपयोग किया जा सकता है

D

Decorator pattern is obsolete and replaced by dependency injection in modern frameworks डेकोरेटर पैटर्न अप्रचलित है और आधुनिक ढांचे में निर्भरता इंजेक्शन द्वारा प्रतिस्थापित किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) If you need Logging + Buffering + Compression on a stream, inheritance requires LoggingBufferingCompressingStream (6 classes for 3 features × 2 on/off states). Decorator composes dynamically: new LoggingStream(new BufferingStream(new CompressingStream(base))). The wrapped object doesn't know it's being decorated (polymorphism). Java's I/O streams and Python's function decorators are canonical implementations.

व्याख्या (हिन्दी) यदि आपको किसी स्ट्रीम पर लॉगिंग + बफ़रिंग + संपीड़न की आवश्यकता है, तो इनहेरिटेंस के लिए लॉगिंगबफ़रिंगकंप्रेसिंगस्ट्रीम (3 सुविधाओं के लिए 6 कक्षाएं × 2 चालू/बंद स्थिति) की आवश्यकता होती है। डेकोरेटर गतिशील रूप से रचना करता है: नया लॉगिंगस्ट्रीम(नया बफ़रिंगस्ट्रीम(नया कंप्रेसिंगस्ट्रीम(बेस)))। लिपटी हुई वस्तु को पता नहीं चलता कि उसे सजाया जा रहा है (बहुरूपता)। जावा की I/O स्ट्रीम और पायथन के फ़ंक्शन डेकोरेटर विहित कार्यान्वयन हैं।

2300

EN + हिं Easy

GB What is 'software metrics' in design quality measurement and what does the CK suite specifically measure?

IN डिज़ाइन गुणवत्ता माप में 'सॉफ़्टवेयर मेट्रिक्स' क्या है और सीके सुइट विशेष रूप से क्या मापता है?

A

CK suite measures code compilation time and binary executable size सीके सुइट कोड संकलन समय और बाइनरी निष्पादन योग्य आकार को मापता है

B

CK (Chidamber and Kemerer) suite measures OO design quality: WMC (Weighted Methods per Class), DIT (Depth of Inheritance Tree), NOC (Number of Children), CBO (Coupling Between Objects), RFC (Response for a Class), LCOM (Lack of Cohesion in Methods) सीके (चिदम्बर और केमेरर) सुइट ओओ डिजाइन गुणवत्ता को मापता है: डब्ल्यूएमसी (प्रति कक्षा भारित तरीके), डीआईटी (विरासत वृक्ष की गहराई), एनओसी (बच्चों की संख्या), सीबीओ (वस्तुओं के बीच युग्मन), आरएफसी (एक कक्षा के लिए प्रतिक्रिया), एलसीओएम (तरीकों में सामंजस्य की कमी)

C

CK suite only measures performance characteristics of running Java programs सीके सुइट केवल जावा प्रोग्राम चलाने की प्रदर्शन विशेषताओं को मापता है

D

CK metrics are only applicable to C++ programs with explicit class hierarchies सीके मेट्रिक्स केवल स्पष्ट वर्ग पदानुक्रम वाले C++ प्रोग्रामों पर लागू होते हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) CK metrics quantify design properties: WMC (high = God class risk), DIT (high = fragile base class risk), CBO (high = high coupling, maintenance risk), LCOM (high = low cohesion, should be split). Research (Basili, Briand, Melo) empirically correlated CK metrics with fault-proneness — high CBO and WMC consistently predict classes likely to contain defects, enabling risk-based code review prioritisation.

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

2301

EN + हिं Easy

GB What is the 'template method pattern' and what specific control flow problem does it solve?

IN 'टेम्पलेट विधि पैटर्न' क्या है और यह किस विशिष्ट नियंत्रण प्रवाह समस्या का समाधान करता है?

A

Template method pattern generates HTML templates from data models automatically टेम्प्लेट विधि पैटर्न स्वचालित रूप से डेटा मॉडल से HTML टेम्प्लेट उत्पन्न करता है

B

Template method defines a skeleton algorithm in a base class with abstract steps implemented by subclasses — solving the problem of algorithm variants that share the same skeleton but differ in specific steps, without duplicating the skeleton in each variant टेम्प्लेट विधि उपवर्गों द्वारा कार्यान्वित अमूर्त चरणों के साथ बेस क्लास में एक कंकाल एल्गोरिदम को परिभाषित करती है - एल्गोरिदम वेरिएंट की समस्या को हल करना जो समान कंकाल साझा करते हैं लेकिन विशिष्ट चरणों में भिन्न होते हैं, प्रत्येक संस्करण में कंकाल को डुप्लिकेट किए बिना

C

Template method pattern is only applicable to report generation and document processing applications टेम्प्लेट विधि पैटर्न केवल रिपोर्ट निर्माण और दस्तावेज़ प्रसंस्करण अनुप्रयोगों पर लागू होता है

D

Template method pattern violates OCP because the base class must be modified to add new variants टेम्प्लेट विधि पैटर्न OCP का उल्लंघन करता है क्योंकि नए वेरिएंट जोड़ने के लिए बेस क्लास को संशोधित किया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Classic use: a data mining framework processes reports (read data → analyse → generate output). Reading and generating vary by format (CSV vs XML vs JSON), but the analysis skeleton is identical. Template method puts the skeleton in AbstractMiner.mine(); subclasses override readData() and generateOutput(). This is the Hollywood Principle: 'Don't call us, we'll call you' — the framework controls flow; subclasses provide variation points.

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

2302

EN + हिं Easy

GB What is 'design by committee' anti-pattern and why does it produce poor software architecture?

IN 'कमेटी द्वारा डिज़ाइन' विरोधी पैटर्न क्या है और यह खराब सॉफ़्टवेयर आर्किटेक्चर क्यों उत्पन्न करता है?

A

Design by committee means senior architects make all design decisions without developer input समिति द्वारा डिज़ाइन का मतलब है कि वरिष्ठ आर्किटेक्ट डेवलपर इनपुट के बिना सभी डिज़ाइन निर्णय लेते हैं

B

Design by committee occurs when too many stakeholders have equal authority over design decisions — producing incoherent architectures that are compromises between conflicting visions, lacking the conceptual integrity that a single architectural mind would provide समिति द्वारा डिज़ाइन तब होता है जब बहुत से हितधारकों के पास डिज़ाइन निर्णयों पर समान अधिकार होता है - असंगत वास्तुकला का निर्माण होता है जो विरोधाभासी दृष्टि के बीच समझौता होता है, जिसमें वैचारिक अखंडता की कमी होती है जो एक एकल वास्तुशिल्प दिमाग प्रदान करेगा

C

Design by committee produces better results because diverse perspectives prevent architectural mistakes समिति द्वारा डिजाइन बेहतर परिणाम देता है क्योंकि विविध दृष्टिकोण वास्तु संबंधी गलतियों को रोकते हैं

D

Design by committee only occurs in open-source projects where no one has final authority समिति द्वारा डिज़ाइन केवल ओपन-सोर्स परियोजनाओं में होता है जहाँ किसी के पास अंतिम अधिकार नहीं होता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Brooks (The Mythical Man-Month) identified conceptual integrity as the most important system quality — achievable when one mind (or a small set of minds sharing a vision) controls the design. When design is fragmented across committees, each decision is a negotiated compromise that no participant fully owns. The result: TCP/IP (one design team) vs OSI (committee) illustrates the difference in elegance and implementation ease.

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

2303

EN + हिं Easy

GB What is the 'proxy pattern' and what three distinct use cases does it address?

IN 'प्रॉक्सी पैटर्न' क्या है और यह किन तीन विशिष्ट उपयोग मामलों को संबोधित करता है?

A

Proxy pattern is a network communication protocol for software components प्रॉक्सी पैटर्न सॉफ्टवेयर घटकों के लिए एक नेटवर्क संचार प्रोटोकॉल है

B

Proxy wraps an object to control access — three uses: Virtual proxy (lazy loading of expensive objects), Remote proxy (local representation of a remote object), Protection proxy (access control/authentication before delegating to real object) पहुंच को नियंत्रित करने के लिए प्रॉक्सी किसी ऑब्जेक्ट को लपेटता है - तीन उपयोग: वर्चुअल प्रॉक्सी (महंगी वस्तुओं की आलसी लोडिंग), रिमोट प्रॉक्सी (दूरस्थ वस्तु का स्थानीय प्रतिनिधित्व), सुरक्षा प्रॉक्सी (वास्तविक वस्तु को सौंपने से पहले पहुंच नियंत्रण/प्रमाणीकरण)

C

Proxy pattern is only used in web applications for HTTP request routing प्रॉक्सी पैटर्न का उपयोग केवल HTTP अनुरोध रूटिंग के लिए वेब अनुप्रयोगों में किया जाता है

D

Proxy and Decorator patterns solve identical problems and should be used interchangeably प्रॉक्सी और डेकोरेटर पैटर्न समान समस्याओं का समाधान करते हैं और इन्हें परस्पर उपयोग किया जाना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Virtual proxy: a HighResolutionImage proxy loads the image only when display() is called, not at construction — avoiding expensive loading until needed. Remote proxy: EJB remote stubs marshal calls across the network transparently. Protection proxy: an AdminServiceProxy checks permissions before delegating to AdminService. All three share the same structural pattern but serve radically different purposes.

व्याख्या (हिन्दी) वर्चुअल प्रॉक्सी: एक हाईरेजोल्यूशनइमेज प्रॉक्सी छवि को केवल तभी लोड करता है जब डिस्प्ले() कहा जाता है, निर्माण पर नहीं - जरूरत पड़ने तक महंगी लोडिंग से बचें। रिमोट प्रॉक्सी: ईजेबी रिमोट स्टब्स मार्शल नेटवर्क पर पारदर्शी रूप से कॉल करता है। सुरक्षा प्रॉक्सी: एक AdminServiceProxy, AdminService को सौंपने से पहले अनुमतियों की जाँच करता है। तीनों एक ही संरचनात्मक पैटर्न साझा करते हैं लेकिन मौलिक रूप से अलग-अलग उद्देश्यों को पूरा करते हैं।

2304

EN + हिं Easy

GB What is 'semantic versioning' (SemVer) and what does each version component communicate to dependent systems?

IN 'सिमेंटिक वर्जनिंग' (सेमवीर) क्या है और प्रत्येक संस्करण घटक आश्रित प्रणालियों से क्या संचार करता है?

A

SemVer is a database versioning tool used to track schema changes सेमवीर एक डेटाबेस वर्जनिंग टूल है जिसका उपयोग स्कीमा परिवर्तनों को ट्रैक करने के लिए किया जाता है

B

SemVer (MAJOR.MINOR.PATCH) communicates: MAJOR increment = breaking API changes (consumers must update); MINOR = backward-compatible new features; PATCH = backward-compatible bug fixes — enabling automated dependency management decisions सेमवीर (MAJOR.MINOR.PATCH) संचार करता है: प्रमुख वृद्धि = एपीआई परिवर्तनों को तोड़ना (उपभोक्ताओं को अपडेट करना होगा); माइनर = पिछड़े-संगत नई सुविधाएँ; PATCH = बैकवर्ड-संगत बग फिक्स - स्वचालित निर्भरता प्रबंधन निर्णयों को सक्षम करना

C

SemVer only applies to open-source libraries; internal enterprise software uses date-based versioning सेमवीर केवल ओपन-सोर्स लाइब्रेरीज़ पर लागू होता है; आंतरिक एंटरप्राइज़ सॉफ़्टवेयर दिनांक-आधारित संस्करण का उपयोग करता है

D

SemVer's MAJOR version must never exceed 9 per the original specification सेमवीर का प्रमुख संस्करण कभी भी मूल विनिर्देश के अनुसार 9 से अधिक नहीं होना चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) SemVer's power is in machine-readable compatibility signals. npm, Maven, pip all use SemVer to resolve dependency graphs: '~1.2.x' accepts patch updates; '^1.x.x' accepts minor and patch; '1.2.3' pins exactly. MAJOR bumps signal 'your code will break' — critical information that triggers careful upgrade processes versus automatic minor/patch updates.

व्याख्या (हिन्दी) सेमवीर की शक्ति मशीन-पठनीय संगतता संकेतों में है। npm, Maven, pip सभी निर्भरता ग्राफ़ को हल करने के लिए SemiVer का उपयोग करते हैं: '~1.2.x' पैच अपडेट स्वीकार करता है; '^1.x.x' माइनर और पैच स्वीकार करता है; '1.2.3' बिल्कुल पिन। प्रमुख बाधाएं संकेत देती हैं 'आपका कोड टूट जाएगा' - महत्वपूर्ण जानकारी जो स्वचालित लघु/पैच अपडेट की तुलना में सावधानीपूर्वक अपग्रेड प्रक्रियाओं को ट्रिगर करती है।

2305

EN + हिं Easy

GB What is 'literate programming' and what productivity claim did its creator make?

IN 'साक्षर प्रोग्रामिंग' क्या है और इसके निर्माता ने क्या उत्पादकता का दावा किया है?

A

Literate programming is a coding standard requiring comments on every line साक्षर प्रोग्रामिंग एक कोडिंग मानक है जिसमें प्रत्येक पंक्ति पर टिप्पणियों की आवश्यकता होती है

B

Literate programming (Knuth) interweaves human-readable prose explaining the program's design with code snippets in any order — the document is primary; code is extracted by a preprocessor (TANGLE). Knuth claimed it led to his best programs and fewest bugs साक्षर प्रोग्रामिंग (नुथ) मानव-पठनीय गद्य को किसी भी क्रम में कोड स्निपेट के साथ प्रोग्राम के डिज़ाइन को समझाते हुए जोड़ता है - दस्तावेज़ प्राथमिक है; कोड प्रीप्रोसेसर (TANGLE) द्वारा निकाला जाता है। नुथ ने दावा किया कि इससे उनके सर्वोत्तम कार्यक्रम और सबसे कम बग प्राप्त हुए

C

Literate programming requires all variable names to be full English sentences साक्षर प्रोग्रामिंग के लिए आवश्यक है कि सभी चर नाम पूर्ण अंग्रेजी वाक्य हों

D

Literate programming is a deprecated practice replaced by inline documentation tools like Javadoc साक्षर प्रोग्रामिंग एक अप्रचलित अभ्यास है जिसे जावाडोक जैसे इनलाइन दस्तावेज़ीकरण टूल द्वारा प्रतिस्थापित किया गया है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Knuth created WEB (TeX) using literate programming and claimed it produced higher-quality code because the programmer must explain every decision in prose — a form of rubber duck debugging at scale. The primary artefact is a document for humans; the compiler gets the code as a side product. Donald Knuth's TeX has 'virtually no bugs' by many accounts, though literate programming's adoption remained niche due to tooling overhead.

व्याख्या (हिन्दी) नथ ने साक्षर प्रोग्रामिंग का उपयोग करके WEB (TeX) बनाया और दावा किया कि यह उच्च-गुणवत्ता वाला कोड तैयार करता है क्योंकि प्रोग्रामर को हर निर्णय को गद्य में समझाना होगा - बड़े पैमाने पर रबर डक डिबगिंग का एक रूप। प्राथमिक कलाकृति मनुष्यों के लिए एक दस्तावेज़ है; कंपाइलर को साइड प्रोडक्ट के रूप में कोड मिलता है। डोनाल्ड नुथ के TeX में कई खातों के अनुसार 'वस्तुतः कोई बग नहीं' है, हालांकि टूलींग ओवरहेड के कारण साक्षर प्रोग्रामिंग को अपनाना विशिष्ट बना रहा।

2306

EN + हिं Easy

GB What is a 'code review checklist' and what cognitive bias does it specifically counteract?

IN 'कोड समीक्षा चेकलिस्ट' क्या है और यह किस संज्ञानात्मक पूर्वाग्रह का विशेष रूप से प्रतिकार करती है?

A

A code review checklist is an automated tool that verifies compliance with all coding standards कोड समीक्षा चेकलिस्ट एक स्वचालित उपकरण है जो सभी कोडिंग मानकों के अनुपालन की पुष्टि करता है

B

A code review checklist provides explicit prompts for reviewers to inspect specific defect categories — counteracting confirmation bias (reviewers unconsciously confirming the code does what they expect rather than looking for what it does wrong) एक कोड समीक्षा चेकलिस्ट समीक्षकों को विशिष्ट दोष श्रेणियों का निरीक्षण करने के लिए स्पष्ट संकेत प्रदान करती है - पुष्टिकरण पूर्वाग्रह का प्रतिकार करना (समीक्षक अनजाने में यह पुष्टि करते हैं कि कोड वही करता है जो वे अपेक्षा करते हैं बजाय इसके कि यह क्या गलत करता है)

C

Code review checklists are only used for security reviews and not for general code quality reviews कोड समीक्षा चेकलिस्ट का उपयोग केवल सुरक्षा समीक्षाओं के लिए किया जाता है, सामान्य कोड गुणवत्ता समीक्षाओं के लिए नहीं

D

Checklists reduce code review effectiveness by distracting reviewers from the overall code logic चेकलिस्ट समग्र कोड तर्क से समीक्षकों का ध्यान भटकाकर कोड समीक्षा प्रभावशीलता को कम कर देती हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Without checklists, reviewers tend to read code as a narrative (is this comprehensible?) rather than systematically hunting defects. Confirmation bias makes reviewers 'see' what code should do rather than what it actually does. Checklists force explicit consideration of error-prone categories: null pointer handling, thread safety, resource cleanup, error message quality — categories experience shows developers consistently overlook.

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

2307

EN + हिं Easy

GB What is 'dead code' in a codebase and why does it present a specific maintenance risk beyond wasted space?

IN कोडबेस में 'डेड कोड' क्या है और यह व्यर्थ स्थान से परे एक विशिष्ट रखरखाव जोखिम क्यों पेश करता है?

A

Dead code refers to code that is syntactically incorrect and cannot be compiled डेड कोड उस कोड को संदर्भित करता है जो वाक्यात्मक रूप से गलत है और संकलित नहीं किया जा सकता है

B

Dead code is reachable or referenced code that is never actually executed in any deployment scenario — it misleads maintainers about system scope, may contain security vulnerabilities, and creates ambiguity about whether removing it would break something डेड कोड पहुंच योग्य या संदर्भित कोड है जिसे वास्तव में किसी भी परिनियोजन परिदृश्य में कभी निष्पादित नहीं किया जाता है - यह सिस्टम स्कोप के बारे में अनुरक्षकों को गुमराह करता है, इसमें सुरक्षा कमजोरियां हो सकती हैं, और इस बारे में अस्पष्टता पैदा होती है कि इसे हटाने से कुछ टूट जाएगा या नहीं

C

Dead code only exists in interpreted languages; compiled languages automatically eliminate it डेड कोड केवल व्याख्या की गई भाषाओं में मौजूद है; संकलित भाषाएँ इसे स्वचालित रूप से समाप्त कर देती हैं

D

Dead code is always harmless and can safely be ignored without any maintenance impact डेड कोड हमेशा हानिरहित होता है और इसे बिना किसी रखरखाव प्रभाव के सुरक्षित रूप से अनदेखा किया जा सकता है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Dead code misleads: a maintainer studying the codebase for a security audit must spend time understanding code that never runs. Security risk: dead code paths may contain vulnerabilities that were 'safe' because unreachable but could become dangerous if accidentally re-enabled by a configuration change. Ambiguity risk: is this code dead because the feature was removed, or because a bug prevents its execution? Removing it requires investigation.

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

2308

EN + हिं Medium

GB What is the 'strangler fig refactoring' pattern at the code level and how does it differ from its architectural namesake?

IN कोड स्तर पर 'स्ट्रैंगलर फिग रिफैक्टरिंग' पैटर्न क्या है और यह इसके वास्तुशिल्प नाम से कैसे भिन्न है?

A

Both terms describe identical concepts at identical scales of abstraction दोनों शब्द अमूर्तता के समान पैमाने पर समान अवधारणाओं का वर्णन करते हैं

B

At code level, strangler fig refactoring wraps an old implementation with a new interface, routing calls through the wrapper that gradually replaces internal behaviour — it applies the same incremental replacement principle as the architectural pattern but within a single codebase कोड स्तर पर, स्ट्रैंगलर फ़िग रिफैक्टरिंग एक पुराने कार्यान्वयन को एक नए इंटरफ़ेस के साथ लपेटता है, रैपर के माध्यम से कॉल को रूट करता है जो धीरे-धीरे आंतरिक व्यवहार को बदल देता है - यह वास्तुशिल्प पैटर्न के समान वृद्धिशील प्रतिस्थापन सिद्धांत को लागू करता है लेकिन एक ही कोडबेस के भीतर

C

Strangler fig refactoring requires the old code to be deleted before the new code is written स्ट्रैंग्लर अंजीर रीफैक्टरिंग के लिए नया कोड लिखने से पहले पुराने कोड को हटाना आवश्यक है

D

Strangler fig refactoring is only applicable to database stored procedures, not application code स्ट्रैंगलर अंजीर रीफैक्टरिंग केवल डेटाबेस संग्रहीत प्रक्रियाओं पर लागू होती है, एप्लिकेशन कोड पर नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The same risk-management principle scales down: instead of routing HTTP traffic, you introduce an abstraction layer (interface) over a messy class; new callers use the interface; old callers are gradually migrated; the old implementation is replaced behind the interface. At any point both old and new implementations coexist safely. This enables refactoring large untested legacy classes without a risky all-at-once rewrite.

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

2309

EN + हिं Easy

GB What is 'naming convention' beyond simple formatting, and what cognitive science principle underlies good identifier naming?

IN सरल स्वरूपण से परे 'नामकरण परंपरा' क्या है, और कौन सा संज्ञानात्मक विज्ञान सिद्धांत अच्छे पहचानकर्ता नामकरण का आधार है?

A

Naming conventions are purely cosmetic and have no measurable impact on code quality नामकरण परंपराएं पूरी तरह से दिखावटी हैं और कोड गुणवत्ता पर इनका कोई मापने योग्य प्रभाव नहीं पड़ता है

B

Good identifier naming encodes domain concepts, intent, and level of abstraction — grounded in the cognitive principle that working memory is limited (Miller's law: 7±2 chunks) and meaningful names reduce cognitive load by making identifiers carry semantic content rather than requiring decode from arbitrary symbols अच्छा पहचानकर्ता नामकरण डोमेन अवधारणाओं, इरादे और अमूर्तता के स्तर को एनकोड करता है - संज्ञानात्मक सिद्धांत पर आधारित है कि कार्यशील मेमोरी सीमित है (मिलर का नियम: 7 ± 2 खंड) और सार्थक नाम पहचानकर्ताओं को मनमाने प्रतीकों से डिकोड की आवश्यकता के बजाय अर्थपूर्ण सामग्री बनाकर संज्ञानात्मक भार को कम करते हैं।

C

The only naming rule that matters is avoiding reserved keywords of the programming language एकमात्र नामकरण नियम जो मायने रखता है वह है प्रोग्रामिंग भाषा के आरक्षित कीवर्ड से बचना

D

Naming conventions should be enforced differently for each type of developer (junior vs senior) प्रत्येक प्रकार के डेवलपर (कनिष्ठ बनाम वरिष्ठ) के लिए नामकरण परंपराएँ अलग-अलग लागू की जानी चाहिए

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Miller's Law: working memory holds 7±2 chunks. Names like 'x', 'temp', 'd' offer zero semantic content — programmers must decode them from context, consuming working memory slots. Names like 'accountBalanceAfterFees', 'isEmailVerified', 'maxRetryAttempts' encode their meaning directly. Research (Buse and Weimer, Feitelson et al.) shows that poor naming is the top contributor to code incomprehensibility — more than missing comments.

व्याख्या (हिन्दी) मिलर का नियम: कार्यशील मेमोरी में 7±2 भाग होते हैं। 'x', 'temp', 'd' जैसे नाम शून्य अर्थ सामग्री प्रदान करते हैं - प्रोग्रामर को कार्यशील मेमोरी स्लॉट का उपभोग करते हुए उन्हें संदर्भ से डिकोड करना होगा। 'accountBalanceAfterFees', 'isEmailVerified', 'maxRetryAttempts' जैसे नाम सीधे अपने अर्थ को कूटबद्ध करते हैं। अनुसंधान (बुसे और वीमर, फीटेलसन एट अल.) से पता चलता है कि खराब नामकरण कोड की समझ से बाहर होने में शीर्ष योगदानकर्ता है - गायब टिप्पणियों से भी अधिक।

2310

EN + हिं Medium

GB What is 'code coverage' as a metric and why is 100% code coverage NOT sufficient evidence of adequate testing?

IN एक मीट्रिक के रूप में 'कोड कवरेज' क्या है और 100% कोड कवरेज पर्याप्त परीक्षण का पर्याप्त प्रमाण क्यों नहीं है?

A

100% code coverage proves the system has no remaining defects 100% कोड कवरेज साबित करता है कि सिस्टम में कोई शेष दोष नहीं है

B

Code coverage measures which lines/branches are executed during testing; 100% coverage is insufficient because coverage only proves code was executed, not that correct assertions were made — a test with no assertions achieves 100% coverage while detecting zero defects कोड कवरेज मापता है कि परीक्षण के दौरान कौन सी लाइनें/शाखाएं निष्पादित की जाती हैं; 100% कवरेज अपर्याप्त है क्योंकि कवरेज केवल यह साबित करता है कि कोड निष्पादित किया गया था, यह नहीं कि सही दावे किए गए थे - बिना किसी दावे वाला परीक्षण शून्य दोषों का पता लगाते हुए 100% कवरेज प्राप्त करता है

C

100% code coverage is both sufficient and necessary for ensuring software quality सॉफ़्टवेयर गुणवत्ता सुनिश्चित करने के लिए 100% कोड कवरेज पर्याप्त और आवश्यक दोनों है

D

Code coverage metrics are only valid for C and Java; not for Python or JavaScript कोड कवरेज मेट्रिक्स केवल C और Java के लिए मान्य हैं; पायथन या जावास्क्रिप्ट के लिए नहीं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) The 'test without assertion' problem: a test that calls every method but asserts nothing achieves 100% coverage and catches nothing. Coverage tells you what was exercised; mutation testing tells you whether tests would detect errors. Coverage is a floor ('at least we ran this code') not a ceiling ('our tests are good'). High coverage with weak assertions is actually dangerous — it creates false confidence.

व्याख्या (हिन्दी) 'बिना दावे के परीक्षण' समस्या: एक परीक्षण जो हर विधि को कॉल करता है लेकिन दावा करता है कि कुछ भी नहीं 100% कवरेज प्राप्त करता है और कुछ भी नहीं पकड़ता है। कवरेज आपको बताता है कि क्या व्यायाम किया गया था; उत्परिवर्तन परीक्षण आपको बताता है कि क्या परीक्षण त्रुटियों का पता लगाएंगे। कवरेज एक मंजिल है ('कम से कम हमने यह कोड चलाया') कोई छत नहीं ('हमारे परीक्षण अच्छे हैं')। कमजोर दावों के साथ उच्च कवरेज वास्तव में खतरनाक है - यह झूठा आत्मविश्वास पैदा करता है।

Software Engineering — MCQ Practice