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
316
EN + हिं Medium
GB What is the difference between 'stated requirements', 'implied requirements', and 'latent requirements'?
IN 'कथित आवश्यकताओं', 'निहित आवश्यकताओं' और 'अव्यक्त आवश्यकताओं' के बीच क्या अंतर है?
A
All three terms describe the same category of requirements at different levels of documentation सभी तीन शब्द दस्तावेज़ीकरण के विभिन्न स्तरों पर आवश्यकताओं की समान श्रेणी का वर्णन करते हैं
B
Stated: explicitly requested by stakeholders; Implied: expected by convention but not stated (e.g., system should not lose data); Latent: unknown even to stakeholders until they experience a prototype — all three must be elicited for a complete system कहा गया: हितधारकों द्वारा स्पष्ट रूप से अनुरोध किया गया; निहित: सम्मेलन द्वारा अपेक्षित लेकिन बताया नहीं गया (उदाहरण के लिए, सिस्टम को डेटा नहीं खोना चाहिए); अव्यक्त: हितधारकों के लिए भी अज्ञात है जब तक कि वे एक प्रोटोटाइप का अनुभव नहीं करते हैं - इन तीनों को एक संपूर्ण प्रणाली के लिए प्राप्त किया जाना चाहिए
C
Stated requirements are formal; implied and latent are informal and should be excluded from SRS बताई गई आवश्यकताएँ औपचारिक हैं; निहित और अव्यक्त अनौपचारिक हैं और इन्हें एसआरएस से बाहर रखा जाना चाहिए
D
Latent requirements only arise from compliance and regulatory sources अव्यक्त आवश्यकताएँ केवल अनुपालन और नियामक स्रोतों से उत्पन्न होती हैं
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Kano model (applied to requirements) distinguishes: basic needs (implied — if absent, dissatisfied; if present, neutral); performance needs (stated — satisfaction proportional to fulfilment); and excitement needs (latent — unexpected delighters). Missing implied requirements causes product rejection; discovering latent requirements creates competitive differentiation. Effective elicitation must target all three categories.
व्याख्या (हिन्दी) कानो मॉडल (आवश्यकताओं पर लागू) अंतर करता है: बुनियादी ज़रूरतें (अंतर्निहित - यदि अनुपस्थित है, असंतुष्ट; यदि मौजूद है, तो तटस्थ); प्रदर्शन की आवश्यकताएं (बताया गया - पूर्ति के लिए आनुपातिक संतुष्टि); और उत्साह की आवश्यकताएं (अव्यक्त - अप्रत्याशित प्रसन्नता)। निहित आवश्यकताओं का अभाव उत्पाद अस्वीकृति का कारण बनता है; अव्यक्त आवश्यकताओं की खोज प्रतिस्पर्धी भेदभाव पैदा करती है। प्रभावी उद्बोधन को सभी तीन श्रेणियों को लक्षित करना चाहिए।
317
EN + हिं Easy
GB What is 'specification by example' (SBE) and what advantage does it offer over traditional requirement statements?
IN 'उदाहरण द्वारा विशिष्टता' (एसबीई) क्या है और यह पारंपरिक आवश्यकता विवरणों पर क्या लाभ प्रदान करता है?
A
SBE automatically generates code examples from natural language requirements एसबीई स्वचालित रूप से प्राकृतिक भाषा आवश्यकताओं से कोड उदाहरण उत्पन्न करता है
B
SBE describes requirements through concrete examples of desired system behaviour rather than abstract statements — concrete examples remove ambiguity, serve as acceptance tests, and create shared understanding across business and technical stakeholders एसबीई अमूर्त बयानों के बजाय वांछित सिस्टम व्यवहार के ठोस उदाहरणों के माध्यम से आवश्यकताओं का वर्णन करता है - ठोस उदाहरण अस्पष्टता को दूर करते हैं, स्वीकृति परीक्षण के रूप में कार्य करते हैं, और व्यापार और तकनीकी हितधारकों के बीच साझा समझ पैदा करते हैं।
C
SBE only works for data transformation requirements; it cannot describe user interface behaviour एसबीई केवल डेटा परिवर्तन आवश्यकताओं के लिए काम करता है; यह उपयोगकर्ता इंटरफ़ेस व्यवहार का वर्णन नहीं कर सकता
D
SBE is identical to use case specification with no practical difference in practice एसबीई उपयोग केस विनिर्देश के समान है और व्यवहार में कोई व्यावहारिक अंतर नहीं है
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Gojko Adzic's SBE replaces vague requirement statements ('the system shall calculate tax correctly') with concrete examples ('given order $100 in CA, tax should be $8.75; given order $100 in OR, tax should be $0'). The concrete example is unambiguous, immediately testable as an acceptance criterion, and communicates the same requirement to both business stakeholders and developers without translation loss.
व्याख्या (हिन्दी) गोज्को एडज़िक का एसबीई अस्पष्ट आवश्यकता कथनों ('सिस्टम कर की सही गणना करेगा') को ठोस उदाहरणों से बदल देता है ('सीए में $100 का ऑर्डर दिया गया है, टैक्स $8.75 होना चाहिए; OR में ऑर्डर $100 दिया गया है, टैक्स $0 होना चाहिए')। ठोस उदाहरण स्पष्ट है, स्वीकृति मानदंड के रूप में तुरंत परीक्षण योग्य है, और अनुवाद हानि के बिना व्यावसायिक हितधारकों और डेवलपर्स दोनों को समान आवश्यकता बताता है।
318
EN + हिं Easy
GB What is the 'requirements conflict' problem in multi-stakeholder systems and what resolution strategies exist?
IN बहु-हितधारक प्रणालियों में 'आवश्यकताओं के टकराव' की समस्या क्या है और कौन सी समाधान रणनीतियाँ मौजूद हैं?
A
Requirements conflicts only occur when two stakeholders are from different departments आवश्यकताओं का टकराव तभी होता है जब दो हितधारक अलग-अलग विभागों से होते हैं
B
Requirements conflicts arise when stakeholders have incompatible needs (e.g., security vs usability, performance vs cost); resolutions include: negotiation to find compromise, creating priority rankings, architectural solutions satisfying both, or explicitly deferring one requirement आवश्यकताओं में टकराव तब उत्पन्न होता है जब हितधारकों की ज़रूरतें असंगत होती हैं (उदाहरण के लिए, सुरक्षा बनाम प्रयोज्यता, प्रदर्शन बनाम लागत); संकल्पों में शामिल हैं: समझौता खोजने के लिए बातचीत, प्राथमिकता रैंकिंग बनाना, दोनों को संतुष्ट करने वाले वास्तुशिल्प समाधान, या स्पष्ट रूप से एक आवश्यकता को स्थगित करना
C
Requirements conflicts are always resolvable by selecting the higher-authority stakeholder's requirement आवश्यकताओं के टकराव को हमेशा उच्च-प्राधिकरण हितधारक की आवश्यकता का चयन करके हल किया जा सकता है
D
Requirements conflicts indicate the project should be cancelled and restarted with fewer stakeholders आवश्यकताओं के टकराव से संकेत मिलता है कि परियोजना को रद्द कर दिया जाना चाहिए और कम हितधारकों के साथ फिर से शुरू किया जाना चाहिए
✅ Correct Answer:
💡 Explanation / व्याख्या
Explanation (English) Security vs. usability is a classic conflict: strong passwords reduce usability; multi-factor authentication adds friction. Resolution strategies: negotiation (find acceptable balance), viewpoint-specific requirements (different security levels for different user roles), architectural patterns (secure defaults with streamlined UX), or explicit management decision to defer one in favour of the other with documented rationale.
व्याख्या (हिन्दी) सुरक्षा बनाम प्रयोज्यता एक क्लासिक संघर्ष है: मजबूत पासवर्ड प्रयोज्यता को कम करते हैं; बहु-कारक प्रमाणीकरण घर्षण जोड़ता है। समाधान रणनीतियाँ: बातचीत (स्वीकार्य संतुलन ढूँढना), दृष्टिकोण-विशिष्ट आवश्यकताएँ (विभिन्न उपयोगकर्ता भूमिकाओं के लिए अलग-अलग सुरक्षा स्तर), वास्तुशिल्प पैटर्न (सुव्यवस्थित यूएक्स के साथ सुरक्षित डिफ़ॉल्ट), या दस्तावेजी तर्क के साथ एक को दूसरे के पक्ष में टालने का स्पष्ट प्रबंधन निर्णय।
319
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) एक प्रशिक्षित सुविधाकर्ता के साथ सभी हितधारकों को एक साथ इकट्ठा करता है। संघर्ष तुरंत सामने आते हैं, कमरे में बातचीत की जाती है, और सर्वसम्मति दर्ज की जाती है - दस्तावेज़ चक्र के सप्ताहों को दिनों में संपीड़ित करना।
320
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 के बिना व्यावसायिक तर्क का परीक्षण करने की अनुमति मिलती है; अवलोकन योग्य स्थिति (केवल प्रभावों के माध्यम से नहीं) राज्य सत्यापन को सक्षम बनाती है।
321
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 बदनाम है।
322
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 क्लास बनाना। रणनीति और टेम्पलेट विधि पैटर्न विहित ओसीपी कार्यान्वयन हैं - नई रणनीतियाँ स्थिर कोर को संशोधित किए बिना डिजाइन का विस्तार करती हैं।
323
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 को कार्यान्वित करता है। यह कार्यान्वयन कक्षाओं को अनुचित जिम्मेदारियों से बोझिल होने से रोकता है।
324
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 स्ट्रीम और पायथन के फ़ंक्शन डेकोरेटर विहित कार्यान्वयन हैं।
325
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.
व्याख्या (हिन्दी) सीके मेट्रिक्स डिजाइन गुणों को मापता है: डब्ल्यूएमसी (उच्च = भगवान वर्ग जोखिम), डीआईटी (उच्च = नाजुक बेस क्लास जोखिम), सीबीओ (उच्च = उच्च युग्मन, रखरखाव जोखिम), एलसीओएम (उच्च = निम्न सामंजस्य, विभाजित किया जाना चाहिए)। अनुसंधान (बेसिली, ब्रायंड, मेलो) ने अनुभवजन्य रूप से सीके मेट्रिक्स को दोष-प्रवणता के साथ सहसंबद्ध किया - उच्च सीबीओ और डब्लूएमसी लगातार उन वर्गों की भविष्यवाणी करते हैं जिनमें दोष होने की संभावना है, जिससे जोखिम-आधारित कोड समीक्षा प्राथमिकता को सक्षम किया जा सके।
326
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() को ओवरराइड करते हैं। यह हॉलीवुड सिद्धांत है: 'हमें कॉल न करें, हम आपको कॉल करेंगे' - ढांचा प्रवाह को नियंत्रित करता है; उपवर्ग भिन्नता अंक प्रदान करते हैं।
327
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.
व्याख्या (हिन्दी) ब्रूक्स (द मिथिकल मैन-मंथ) ने वैचारिक अखंडता को सबसे महत्वपूर्ण प्रणाली गुणवत्ता के रूप में पहचाना - यह तब प्राप्त होता है जब एक दिमाग (या एक दृष्टिकोण साझा करने वाले दिमागों का एक छोटा समूह) डिजाइन को नियंत्रित करता है। जब डिज़ाइन को समितियों में विभाजित किया जाता है, तो प्रत्येक निर्णय एक समझौता समझौता होता है जिसका पूर्ण स्वामित्व किसी भी भागीदार के पास नहीं होता है। परिणाम: टीसीपी/आईपी (एक डिजाइन टीम) बनाम ओएसआई (समिति) सुंदरता और कार्यान्वयन में आसानी के अंतर को दर्शाता है।
328
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 को सौंपने से पहले अनुमतियों की जाँच करता है। तीनों एक ही संरचनात्मक पैटर्न साझा करते हैं लेकिन मौलिक रूप से अलग-अलग उद्देश्यों को पूरा करते हैं।
329
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' बिल्कुल पिन। प्रमुख बाधाएं संकेत देती हैं 'आपका कोड टूट जाएगा' - महत्वपूर्ण जानकारी जो स्वचालित लघु/पैच अपडेट की तुलना में सावधानीपूर्वक अपग्रेड प्रक्रियाओं को ट्रिगर करती है।
330
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 में कई खातों के अनुसार 'वस्तुतः कोई बग नहीं' है, हालांकि टूलींग ओवरहेड के कारण साक्षर प्रोग्रामिंग को अपनाना विशिष्ट बना रहा।
316–330 of 647