---
title: "Discussion on \"How “Design Patterns Explained” Changed the Way I Design Software\" | Hashnode"
description: "Discussion on \"How “Design Patterns Explained” Changed the Way I Design Software\". I read Design Patterns Explained 2nd Edition a few months ago. I thought I'd finally write about it and some of the lessons I took away from it.I was reading the final chapters while starting Offline"
url: "https://hashnode.com/posts/how-design-patterns-explained-changed-the-way-i-design-software/6a1f22bc545c8a206ce1f536"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [How “Design Patterns Explained” Changed the Way I Design Software](https://blog.nikkigoel.com/how-design-patterns-explained-changed-the-way-i-design-software?utm_source=hashnode&utm_medium=feed)

I read Design Patterns Explained 2nd Edition a few months ago. I thought I'd finally write about it and some of the lessons I took away from it.I was reading the final chapters while starting Offline

Jun 2 · 7 min read · blog.nikkigoel.com  
Updated Jun 5  
Read the article

-   [#bookreview](https://hashnode.com/tag/bookreview)
-   [#design-patterns](https://hashnode.com/tag/design-patterns)
-   [#architecture](https://hashnode.com/tag/architecture)
-   [#devlog](https://hashnode.com/tag/devlog)
-   [#software-engineering](https://hashnode.com/tag/software-engineering)

## Written by

[Nikki Goel](https://hashnode.com/@nicks101)

@nicks101 · India

  
[View profile](https://hashnode.com/@nicks101)

Software Engineer | Blogger | Flutter Developer

I build apps, internal tools, and sketch stuff on my iPad. Into side projects, and occasionally sharing thoughts here.

## Responses 4

Markdown supported · ⌘↵ to post

[Jun 4](https://hashnode.com/posts/how-design-patterns-explained-changed-the-way-i-design-software/6a1f22bc545c8a206ce1f536/comment/6a20f0802f611e6372c954ca)

This is a great breakdown of how design patterns shift the focus from 'making it work' to 'making it maintainable.' I’ve found that the real shift happens when you stop seeing patterns as just theoretical structures and start seeing them as solutions to specific 'code smell' scenarios.

For anyone currently digging into these patterns, I’ve been working on a tool that summarizes technical deep-dives and video documentation into concise, readable formats. It’s been helping me get through architectural documentation much faster—you can check it out at ytskim.com.

Out of curiosity, which pattern did you find had the steepest learning curve when you first started applying it to production code? For me, it was definitely getting comfortable with the Strategy Pattern versus just relying on overloaded conditionals.

[Nikki Goel](https://hashnode.com/@nicks101)

[Jun 4](https://hashnode.com/posts/how-design-patterns-explained-changed-the-way-i-design-software/6a1f22bc545c8a206ce1f536/comment/6a20f0802f611e6372c954ca#reply-6a21189e51b7da48da55177c)

I don't remember which pattern had the steepest learning curve for me, but the Bridge Pattern certainly took a while to click. It has quite a few moving parts, and the naming conventions can be a bit confusing when you're first learning it.

My usual approach is to look at lots of examples, then map the implementation to a UML diagram so I can clearly identify the different components and their responsibilities.

After that, I try to implement it myself as an exercise. The real test, though, is being able to recognise when a pattern is actually needed while designing or refactoring code. That's usually when the pattern truly starts to make sense.

[Josh Green](https://hashnode.com/@joshgreen)

[Jun 4](https://hashnode.com/posts/how-design-patterns-explained-changed-the-way-i-design-software/6a1f22bc545c8a206ce1f536/comment/6a20f0802f611e6372c954ca#reply-6a21888031e3059f14bd1f89)

The Bridge Pattern really resonates with me. I had a similar experience with Strategy vs just using conditionals everywhere. The book frames it as "what varies vs what stays the same" which sounds simple but it took me a while to actually see it in my own code. The moment I started asking "what's going to change here in 6 months" before writing a new module, the patterns just showed up naturally. Didn't have to force them.

[BridgeXAPI](https://hashnode.com/@bridgexapi)

[Jun 2](https://hashnode.com/posts/how-design-patterns-explained-changed-the-way-i-design-software/6a1f22bc545c8a206ce1f536/comment/6a1f30cd545c8a206ce8a23a)

"What is stable, and what is likely to change?" is probably one of the most useful architecture questions there is. We've been seeing something similar in BXRuntime recently. Several systems evolved independently, but once we started isolating what changes over time, a very different architecture emerged than the one we originally planned.

Great read.