Skip to content

Commit 64de1eb

Browse files
PrathameshDhande22PrathameshDhande22
committed
Quiz Added
1 parent 27d4bdd commit 64de1eb

File tree

2 files changed

+188
-0
lines changed

2 files changed

+188
-0
lines changed

‎content/Quiz-1.md‎

Lines changed: 187 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,187 @@
1+
---
2+
title: Quiz 1
3+
created: 2025-09-03
4+
tags:
5+
- quiz
6+
---
7+
All the Questions are based on Pattern [[Strategy Pattern]], [[Singleton Pattern]], [[Observer Pattern]], [[Factory Method Pattern]], [[Facade Pattern]], [[Decorator Pattern]], [[Adapter Pattern]], [[Command Pattern]], and [[Abstract Factory Pattern]] Explanation is also provided.
8+
9+
#### Question 1
10+
11+
You are building a **payment system** for an e-commerce website.
12+
The system should support multiple payment methods (Credit Card, PayPal, UPI).
13+
The way the payment is processed should be **easily interchangeable** at runtime without changing the core checkout flow.
14+
15+
👉 Which pattern should you use?
16+
> [!FAQ]- Answer & Explanation
17+
> **Pattern**: Strategy Pattern
18+
> **Explanation:**
19+
> - The checkout process (algorithm skeleton) is fixed, but the **payment method (CreditCard/PayPal/UPI)** can change dynamically.
20+
> - Strategy Pattern is used to **define a family of algorithms** (different payment strategies) and make them interchangeable at runtime.
21+
22+
---
23+
#### Question 2
24+
25+
In a **stock market app**, whenever the price of a stock changes, you want all the subscribed users and analytics modules to get notified automatically.
26+
27+
👉 Which pattern fits here?
28+
> [!FAQ]- Answer & Explanation
29+
> **Pattern**: Observer Pattern
30+
> **Explanation:**
31+
> - When the stock (subject) changes, all observers (users, analytics modules) should be automatically notified.
32+
> - Observer Pattern allows **one-to-many dependency** between objects.
33+
34+
---
35+
#### Question 3
36+
37+
You are designing a **coffee shop ordering system**.
38+
A base coffee can be ordered, but customers can add extras like milk, sugar, whip, or mocha — and these add-ons should be flexible and combinable without creating hundreds of coffee subclasses.
39+
40+
👉 Which pattern should you apply?
41+
> [!FAQ]- Answer & Explanation
42+
> **Pattern**: Decorator Pattern
43+
> **Explanation:**
44+
> - Instead of creating subclasses like `CoffeeWithMilkAndSugarAndWhip`, we use the **Decorator Pattern** to wrap objects dynamically with additional functionality.
45+
> - This allows flexible and combinable add-ons.
46+
47+
---
48+
#### Question 4
49+
50+
You want to build a **document creation tool** that allows users to create different types of documents (Word, PDF, Excel).
51+
You need a way to let subclasses decide which type of document object to create without altering the client code.
52+
53+
👉 Which pattern works best?
54+
> [!FAQ]- Answer & Explanation
55+
> **Pattern**: Factory Method Pattern
56+
> **Explanation:**
57+
> - Factory **Method** allows subclasses (`WordDocumentFactory`, `PdfDocumentFactory`) to decide which object to create without changing the client code.
58+
> - Plain **Factory Pattern** is more general, but in GoF terms, this case is specifically **Factory Method**.
59+
60+
---
61+
#### Question 5
62+
63+
You are building a **cross-platform UI toolkit** (Windows, macOS, Linux).
64+
Each platform needs its own **Button, Checkbox, and Dropdown** components.
65+
You want to create families of related objects (UI components) without depending on their concrete classes.
66+
67+
👉 Which pattern should you use?
68+
> [!FAQ]- Answer & Explanation
69+
> **Pattern**: Abstract Factory Pattern
70+
> **Explanation:**
71+
> - Each platform (Windows/macOS/Linux) needs a **family of related objects** (Button, Checkbox, Dropdown).
72+
> - Abstract Factory provides an interface to create families of related objects **without specifying their concrete classes**.
73+
74+
---
75+
#### Question 6
76+
77+
In your application, you need to ensure that there is **only one instance of a logging service** available throughout the system, and it should be globally accessible.
78+
79+
👉 Which pattern fits here?
80+
> [!FAQ]- Answer & Explanation
81+
> **Pattern**: Singleton Pattern
82+
> **Explanation:**
83+
> - Singleton ensures **only one instance** of a class exists and provides a **global access point** to it.
84+
> - Perfect for cases like logging service, configuration manager, database connection pool.
85+
86+
---
87+
#### Question 7
88+
89+
You are designing a **remote control system** for a smart home.
90+
Each button (e.g., Light On, Light Off, Fan On, Fan Off) should trigger a specific action.
91+
You want to encapsulate these requests as objects so that you can also **undo/redo actions** later.
92+
93+
👉 Which pattern is most suitable?
94+
> [!FAQ]- Answer & Explanation
95+
> **Pattern**: Command Pattern
96+
> **Explanation:**
97+
> - Each button press is a **command** (`LightOnCommand`, `FanOffCommand`, etc.).
98+
> - Commands can be stored in a history stack to **undo/redo** actions.
99+
> - Very common in remote controls, menu actions, and macro recording.
100+
101+
---
102+
#### Question 8
103+
104+
You are integrating a **third-party payment gateway** into your existing e-commerce system.
105+
The interface of the third-party gateway is incompatible with your current system’s payment interface.
106+
You need a way to make them work together without changing existing code.
107+
108+
👉 Which pattern should you apply?
109+
> [!FAQ]- Answer & Explanation
110+
> **Pattern**: Adapter Pattern
111+
> **Explanation:**
112+
> - Your system expects a specific **payment interface**, but the third-party gateway has a different API.
113+
> - Adapter Pattern acts as a **bridge** between the two incompatible interfaces.
114+
115+
---
116+
#### Question 9
117+
118+
You are designing a **complex library management system** with multiple subsystems (catalog, user management, notifications, reporting).
119+
You want to provide a **simplified interface** to these subsystems, so clients don’t have to deal with the complexity directly.
120+
121+
👉 Which pattern should you use?
122+
> [!FAQ]- Answer & Explanation
123+
> **Pattern**: Facade Pattern
124+
> **Explanation:**
125+
> - You have many complex subsystems (catalog, user, notifications, reporting).
126+
> - Facade Pattern provides a **unified, simplified interface** so clients don’t need to know the internal details.
127+
128+
---
129+
#### Trick Question 1
130+
131+
You are building a **text editor**.
132+
- You want to support multiple text formatting operations (bold, italic, underline).
133+
- You also want to support an **undo/redo system** for these operations.
134+
- Additionally, you may want to store a history of commands for “macro recording” (replaying a sequence of edits).
135+
136+
👉 Which pattern fits best?
137+
> [!FAQ]- Answer & Explanation
138+
> **Pattern**: Command Pattern
139+
> **Explanation:**
140+
> - Each operation is a **Command object**.
141+
> - Commands can be stored in a **history stack** to support **undo/redo**.
142+
> - They can also be replayed for macro recording.
143+
144+
---
145+
#### Trick Question 2
146+
147+
In a **video game**, you have different types of enemies (Orc, Troll, Dragon).
148+
- Each enemy has different attack behaviors (melee, ranged, magic).
149+
- You want to change enemy behaviors **dynamically at runtime** (e.g., make Troll use ranged attack instead of melee).
150+
151+
👉 Which pattern should you choose?
152+
> [!FAQ]- Answer & Explanation
153+
> **Pattern**: Strategy Pattern
154+
> **Explanation:**
155+
> - Attack behavior is the **algorithm** that can vary independently from the Enemy class.
156+
> - With Strategy, you can swap behaviors dynamically at runtime (`meleeAttack`, `rangedAttack`, `magicAttack`).
157+
158+
---
159+
#### Trick Question 3
160+
161+
You are working on a **plugin-based architecture**.
162+
- A core application should be able to load different plugins (authentication, reporting, visualization) **without modifying its source code**.
163+
- The plugins should conform to a common interface, but the actual plugin implementations may vary.
164+
165+
👉 Which pattern makes the most sense here?
166+
> [!FAQ]- Answer & Explanation
167+
> **Pattern**: Factory Method (or Abstract Factory if multiple families)
168+
> **Explanation:**
169+
> - Adapter is for **incompatible interfaces** (not the case here).
170+
> - The correct approach is **Factory Method**: the core app knows only the `Plugin` interface and lets factories decide which plugin implementation to instantiate at runtime.
171+
172+
---
173+
#### Trick Question 4
174+
175+
You are designing a **shopping cart system**.
176+
- Discounts can be applied in different ways: percentage discount, flat discount, buy-one-get-one.
177+
- You also want to allow **stacking discounts** (e.g., percentage + flat).
178+
179+
👉 Which pattern should you use?
180+
> [!FAQ]- Answer & Explanation
181+
> **Pattern**: Decorator Pattern
182+
> **Explanation:**
183+
> - You start with a base `Discount`.
184+
> - Each discount (percentage, flat, BOGO) can **wrap** the existing discount and add its own behavior.
185+
> - This allows stacking and combining discounts flexibly.
186+
187+
---

‎content/index.md‎

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -126,6 +126,7 @@ Consider an `SQLManager` class that performs CRUD operations. It has an `ILogger
126126
7. [[Command Pattern]]
127127
8. [[Adapter Pattern]]
128128
9. [[Facade Pattern]]
129+
10. [[Quiz-1]]
129130

130131
---
131132
> [!Note]

0 commit comments

Comments
 (0)