I suppose I'm prejudiced.. There's a whole load of "Design Patterns" books that haven't had much of an impact, when you try to read them, many of them have the

I suppose I'm prejudiced.. There's a whole load of "Design Patterns" books that haven't had much of an impact, when you try to read them, many of them have the author's pet idiosyncrasies or preferences in how they interpret patterns. Things like "Java/Python/C# Design patterns" are usually best avoided - especially some authors whose experience is not sufficiently deep, and they've not proven the patterns in a large # of projects. Esp. with a language like Python, where classes are very light-weight (compared with Java, say) , I've seen authors write some dense/opaque English to describe their patterns.. When a book in my coding language makes me, an experienced developer feel dumb .. I can't be helped - either I'm dumb or the book is dumb .. either way , I've wasted good money on yet another patterns book - not again. I like these two brilliant American aphorisms to describe OOPs. First : Everything in its place, and a place for everything. Second : Data + Algorithms = Programs. With Languages like Python, Go, Rust, JavaScript where functions can pretty much rule , and you employ classes where actually needed, OOPs can be summed up as above. Java started the trend of overbearing classes bolted onto every problem ("a solution looking for a problem").