2536

EN + हिं Easy

GB What is the 'requirements workshop' (JAD session) and what specific advantage does joint authoring provide?

IN 'आवश्यकताएँ कार्यशाला' (जेएडी सत्र) क्या है और संयुक्त संलेखन क्या विशिष्ट लाभ प्रदान करता है?

A

JAD sessions are mandatory legal reviews of requirements documents by compliance officers जेएडी सत्र अनुपालन अधिकारियों द्वारा आवश्यकताओं के दस्तावेजों की अनिवार्य कानूनी समीक्षा है

B

JAD (Joint Application Design) brings all stakeholders together in intensive structured workshops to jointly produce requirements — the joint authoring advantage is that conflicts surface and are resolved in real time rather than circulating documents with contradictory comments over weeks जेएडी (संयुक्त अनुप्रयोग डिजाइन) सभी हितधारकों को संयुक्त रूप से आवश्यकताओं को पूरा करने के लिए गहन संरचित कार्यशालाओं में एक साथ लाता है - संयुक्त लेखन का लाभ यह है कि विरोधाभासी टिप्पणियों के साथ दस्तावेजों को हफ्तों तक प्रसारित करने के बजाय संघर्ष सामने आते हैं और वास्तविक समय में हल हो जाते हैं।

C

JAD sessions replace all other requirements techniques and are sufficient alone for any project जेएडी सत्र अन्य सभी आवश्यकताओं की तकनीकों को प्रतिस्थापित करते हैं और किसी भी परियोजना के लिए अकेले पर्याप्त होते हैं

D

JAD sessions are only effective for projects with fewer than five stakeholders JAD सत्र केवल पाँच से कम हितधारकों वाली परियोजनाओं के लिए प्रभावी हैं

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Traditional requirements gathering sends draft documents to stakeholders separately; each returns comments in isolation; contradictions emerge when comments are collated — requiring another round. JAD (IBM, 1977) assembles all stakeholders simultaneously with a trained facilitator. Conflicts surface immediately, are negotiated in the room, and consensus is recorded — compressing weeks of document cycles into days.

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

2537

EN + हिं Easy

GB What is 'design for testability' and what structural properties does it require?

IN 'परीक्षण योग्यता के लिए डिज़ाइन' क्या है और इसके लिए किन संरचनात्मक गुणों की आवश्यकता है?

A

Design for testability means writing tests before writing production code (TDD) परीक्षण योग्यता के लिए डिज़ाइन का अर्थ है उत्पादन कोड (टीडीडी) लिखने से पहले परीक्षण लिखना

B

Design for testability structures software so components can be isolated and tested independently — requiring: well-defined interfaces, dependency injection, avoidance of global state, separation of I/O from logic, and observable internal state परीक्षण योग्यता संरचना सॉफ़्टवेयर के लिए डिज़ाइन ताकि घटकों को अलग किया जा सके और स्वतंत्र रूप से परीक्षण किया जा सके - आवश्यकता है: अच्छी तरह से परिभाषित इंटरफेस, निर्भरता इंजेक्शन, वैश्विक स्थिति से बचाव, तर्क से I/O को अलग करना, और अवलोकन योग्य आंतरिक स्थिति

C

Design for testability only applies to safety-critical systems that require formal verification परीक्षण योग्यता के लिए डिज़ाइन केवल सुरक्षा-महत्वपूर्ण प्रणालियों पर लागू होता है जिन्हें औपचारिक सत्यापन की आवश्यकता होती है

D

Design for testability requires that all code branches be executable with a single test case परीक्षण योग्यता के लिए डिज़ाइन के लिए आवश्यक है कि सभी कोड शाखाएँ एक ही परीक्षण केस के साथ निष्पादन योग्य हों

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) A class with hardcoded database connections cannot be unit-tested without a real database. Design for testability explicitly considers how code will be tested during design: constructor injection enables mock dependencies; pure functions (no side effects) are trivially testable; separating HTTP parsing from business logic allows testing business logic without HTTP; observable state (not just through effects) enables state verification.

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

2538

EN + हिं Easy

GB What is 'interface design' in software engineering and what principles govern API usability?

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

A

Interface design only refers to visual GUI design for end-user applications इंटरफ़ेस डिज़ाइन केवल अंतिम-उपयोगकर्ता अनुप्रयोगों के लिए विज़ुअल GUI डिज़ाइन को संदर्भित करता है

B

Interface design for APIs applies principles of least surprise (behave as expected by experienced users), consistency (similar operations work similarly), minimal surface area (expose only what is needed), and progressive disclosure (simple cases are simple; complex cases are possible) एपीआई के लिए इंटरफ़ेस डिज़ाइन कम से कम आश्चर्य (अनुभवी उपयोगकर्ताओं द्वारा अपेक्षित व्यवहार), स्थिरता (समान संचालन समान रूप से काम करता है), न्यूनतम सतह क्षेत्र (केवल वही प्रदर्शित करें जो आवश्यक है), और प्रगतिशील प्रकटीकरण (सरल मामले सरल हैं; जटिल मामले संभव हैं) के सिद्धांतों को लागू करता है।

C

API design principles are standardised by IEEE and all APIs must conform to IEEE 11801 एपीआई डिज़ाइन सिद्धांत आईईईई द्वारा मानकीकृत हैं और सभी एपीआई को आईईईई 11801 के अनुरूप होना चाहिए

D

Good API design requires formal UML documentation before any API can be released किसी भी एपीआई को जारी करने से पहले अच्छे एपीआई डिज़ाइन के लिए औपचारिक यूएमएल दस्तावेज़ीकरण की आवश्यकता होती है

✅ Correct Answer:

💡 Explanation / व्याख्या

Explanation (English) Principle of Least Surprise (Knuth/POLA): an API behaves the way an experienced user expects. Minimal surface area (don't expose internals): every public API element becomes a maintenance obligation. Consistent naming/semantics reduces learning curve. Progressive disclosure: simple tasks (createUser) require minimal parameters; advanced configuration uses options objects. These principles are why Python's standard library is praised and Win32 API is infamous.

व्याख्या (हिन्दी) कम से कम आश्चर्य का सिद्धांत (नुथ/पोला): एक एपीआई एक अनुभवी उपयोगकर्ता की अपेक्षा के अनुरूप व्यवहार करता है। न्यूनतम सतह क्षेत्र (आंतरिक चीज़ों को उजागर न करें): प्रत्येक सार्वजनिक एपीआई तत्व एक रखरखाव दायित्व बन जाता है। लगातार नामकरण/शब्दार्थ विज्ञान सीखने की अवस्था को कम करता है। प्रगतिशील प्रकटीकरण: सरल कार्यों (createUser) के लिए न्यूनतम मापदंडों की आवश्यकता होती है; उन्नत कॉन्फ़िगरेशन विकल्प ऑब्जेक्ट का उपयोग करता है। इन सिद्धांतों के कारण ही Python की मानक लाइब्रेरी की प्रशंसा की जाती है और Win32 API बदनाम है।

2539

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 क्लास बनाना। रणनीति और टेम्पलेट विधि पैटर्न विहित ओसीपी कार्यान्वयन हैं - नई रणनीतियाँ स्थिर कोर को संशोधित किए बिना डिजाइन का विस्तार करती हैं।

2540

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 को कार्यान्वित करता है। यह कार्यान्वयन कक्षाओं को अनुचित जिम्मेदारियों से बोझिल होने से रोकता है।

2541

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) सिस्टम संगठन का वर्णन करता है: माइक्रोसर्विसेज यह निर्धारित करता है कि प्रक्रिया सीमाओं के पार एक सिस्टम को कैसे विघटित किया जाए; यह कोई डिज़ाइन विवरण नहीं है बल्कि तैनाती, स्केलिंग और टीम संगठन के लिए सिस्टम-व्यापी निहितार्थ के साथ एक मौलिक संरचनात्मक प्रतिबद्धता है।

2542

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 स्ट्रीम और पायथन के फ़ंक्शन डेकोरेटर विहित कार्यान्वयन हैं।

2543

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.

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

2544

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() को ओवरराइड करते हैं। यह हॉलीवुड सिद्धांत है: 'हमें कॉल न करें, हम आपको कॉल करेंगे' - ढांचा प्रवाह को नियंत्रित करता है; उपवर्ग भिन्नता अंक प्रदान करते हैं।

2545

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.

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

2546

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.

व्याख्या (हिन्दी) Virtual proxy: a HighResolutionImage proxy loads the image only when display() is called, not at construction — avoiding expensive loading until needed. रिमोट प्रॉक्सी: ईजेबी रिमोट स्टब्स मार्शल नेटवर्क पर पारदर्शी रूप से कॉल करता है। सुरक्षा प्रॉक्सी: एक AdminServiceProxy, AdminService को सौंपने से पहले अनुमतियों की जाँच करता है। तीनों एक ही संरचनात्मक पैटर्न साझा करते हैं लेकिन मौलिक रूप से अलग-अलग उद्देश्यों को पूरा करते हैं।

2547

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' बिल्कुल पिन। प्रमुख बाधाएं संकेत देती हैं 'आपका कोड टूट जाएगा' - महत्वपूर्ण जानकारी जो स्वचालित लघु/पैच अपडेट की तुलना में सावधानीपूर्वक अपग्रेड प्रक्रियाओं को ट्रिगर करती है।

2548

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 में कई खातों के अनुसार 'वस्तुतः कोई बग नहीं' है, हालांकि टूलींग ओवरहेड के कारण साक्षर प्रोग्रामिंग को अपनाना विशिष्ट बना रहा।

2549

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.

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

2550

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.

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

Software Engineering — MCQ Practice