Reflection of Design Patterns

29 Apr 2026

---

deja-vu isn’t always a bad thing

When people ask about design patterns, I think of them like how kitchens are organized. Plates are usually near the silverware, not because there is a rule, but because it makes sense after enough people have done it that way. In software, design patterns are the same idea. They are common ways to solve problems like organizing code, handling data, or separating responsibilities. Instead of reinventing structure every time, you follow patterns that keep code predictable and easier to work with.

While building the SRCH project, I ended up using these patterns naturally. The structure follows a separation of concerns similar to MVC, where the frontend handles the UI, the backend handles logic, and the database handles data. I also used a Repository style approach by centralizing database access, and a Singleton style for shared resources like database connections. On the frontend, reusable components act like a Composite pattern, building larger features from smaller pieces. None of this was forced, it just came from trying to keep the project clean and scalable.