A scenario-based matching question will come from the design patterns chapter.
| Coverage | Prepare These Topics |
|---|---|
| Design Patterns | Creational, Structural, Behavioral |
Possible topics — study class structure & code:
One long descriptive question will come from design patterns.
A short scenario (2–3 paragraphs). You will be asked to draw one or both diagrams from it.
Identify Actors (Who) and Use Cases (What they do). Draw system boundary, stick figures, ovals, and connection lines.
Extract the flow of steps from the scenario. Include start node, actions, at least one decision diamond (Yes/No), and end node.
A document editor lets users export reports as PDF, Word, or HTML. The editor should call one common method to create the right exporter object, instead of using large if-else blocks in client code.
A logistics app ships orders by truck in cities and by ship for islands. The order system should request a transport object without knowing the exact concrete class used for delivery.
A game creates different enemy characters for desert, snow, and jungle levels. Each level module should decide which enemy object gets instantiated while gameplay code stays unchanged.
A UI toolkit supports Windows and Mac themes. Once a theme is selected, matching buttons, checkboxes, and menus must come from the same family.
A furniture app sells modern and classic collections. Choosing one style should generate sofa, table, and chair from the same design family.
A database tool supports MySQL and PostgreSQL. After selecting one environment, matching connection, command, and transaction objects should be created as a set.
A pizza app lets users choose crust, size, toppings, and sauces. Many optional combinations exist, so the final object should be assembled in readable steps.
A report generator creates reports with optional sections such as charts, summary, and appendix. Different departments need different section combinations.
A computer store lets users configure RAM, CPU, SSD, GPU, and cooling. The object should be built piece by piece instead of using a huge constructor.
A game spawns many soldiers with the same setup and only changes position and health. The engine wants to copy a preconfigured template quickly.
A form designer stores a ready-made layout. Teachers copy the base form for many courses and then edit a few fields.
A dashboard tool loads a heavy widget with defaults. To create similar widgets, it copies the existing configured widget and tweaks few properties.
A logging service should have exactly one shared logger instance used by all classes.
A print server controls one physical printer. Multiple modules request printing, but one manager instance must coordinate access.
A desktop app must use only one session cache controller to avoid inconsistent data across screens.
A payment module expects pay(), but an old library exposes makeTransaction(). A small translator object is needed between them.
A USB-C charger must connect to an HDMI-only projector using a compatibility wrapper.
A Java app expects a standard sender interface, but a third-party API has different method names and parameters.
A remote system has simple/advanced remotes and many device types. Both sides should vary independently.
A shape library has shapes and multiple renderers. Shapes and rendering engines should evolve separately.
Reports and invoices can be exported through PDF or Excel engines. Keep document types separate from export implementations.
A coffee app starts with plain coffee and stacks milk/sugar/cream dynamically at runtime.
A sender works normally, but logging/retry/encryption must be attached in different runtime combinations.
A photo app applies border, watermark, and shadow one after another while keeping same interface.
A file manager must run the same display() operation on both files and folders in a tree structure.
A graphics editor supports groups containing shapes and nested groups; all support the same draw command.
An e-commerce tree has categories/subcategories/products; one operation should work on single product or full category.
A smart home UI buttons should hold action objects so actions can be logged and undone later.
A restaurant queues kitchen tasks for later execution without waiter knowing implementation details.
A scheduler triggers backup/cleanup/report jobs at midnight with logging and retries.
An HR module traverses employees one by one without exposing internal collection structure.
A playlist should support next()/hasNext() regardless of whether songs are stored in array/list/linked structure.
A game inventory custom container should display items in order without direct index access.
When weather updates, multiple displays should refresh automatically.
When product price changes, email/SMS/recommendation services react immediately.
When a new video is uploaded, all subscribers should get alerts while staying loosely coupled.
Students submit hostel complaints with room number, category, and issue text. The warden reviews and assigns each complaint to an electrician, plumber, or carpenter. The assigned staff updates status as In Progress or Resolved. Students can track complaint status and receive a message when resolved.
Students apply online for bus-pass renewal by uploading fee receipt and selecting route. The transport office verifies documents; if valid, the system generates a renewed pass and sends a QR code. If documents are invalid, the request is rejected with reason and student can reapply.
| Scenario Range | Pattern |
|---|---|
| 1-3 | Factory Method |
| 4-6 | Abstract Factory |
| 7-9 | Builder |
| 10-12 | Prototype |
| 13-15 | Singleton |
| 16-18 | Adapter |
| 19-21 | Bridge |
| 22-24 | Decorator |
| 25-27 | Composite |
| 28-30 | Command |
| 31-33 | Iterator |
| 34-36 | Observer |
Actors: Student, Warden, Maintenance Staff.
Main Use Cases: Submit Complaint, Review Complaint, Assign Complaint, Update Status, Track Status, Send Resolution Notification.
System Boundary: Hostel Complaint Management System.
Flow: Start -> Student submits complaint -> Warden reviews -> Assign staff -> Staff updates status.
Decision: Resolved? If No -> back to In Progress. If Yes -> send notification -> End.
Actors: Student, Transport Office.
Main Use Cases: Apply for Renewal, Upload Documents, Verify Documents, Approve Renewal, Reject Renewal, Generate QR Pass, Reapply.
System Boundary: Bus Pass Renewal System.
Flow: Start -> Student submits renewal -> Office verifies documents.
Decision: Documents valid? If Yes -> generate renewed pass + send QR -> End. If No -> reject with reason -> student reapply path -> End.