Design Patterns: Elements of Reusable Object-Oriented Software 1st Edition

This book characterizes the kind of thinking that moves you from the low-level 'small' view of a software developer to the high level long-term view of a software architect.While entry-level and junior developers may spent hours arguing fruitlessly over whether OOP is dead or alive, or whether functional programming is better or worse, most senior engineers and software architects are able to use many different paradigms. They understand that these patterns are deeper than the paradigm they are implemented in.They understand that the concepts and ideas underlying these design patterns cannot and will not ever die because they express evergreen solutions to dealing with evolving software systems.Javascript made the prototype pattern its object model. Generators (and coroutines) that make async/await possible are often implemented as combinations of Factories and Iterators. The Observer pattern underlies almost every single reactive UI framework and most micro-service architectures. Decorators have become mainstays in most languages, inversion of control (IoC) is crucial for dependency injection patterns (Angular, etc.), and on and on... In short... these patterns are used absolutely everywhere, yes, even today.Basically, anyone who says these patterns are dead is either profoundly confused or unaware of how prevalent they are underneath everything they do.For those who say you don't need to know the patterns themselves because they are implemented as language features in modern languages... I would say that coders are generally afraid to use what they don't understand. Have you ever seen someone try to do reactive state management well who didn't understand the Observer pattern? It's not pretty. Moreover, there is no language that offers every single one of these patterns as first-class objects, and certainly no language that has them tailor-made for your use case and your business logic.Understanding the problems that these design patterns solve will help you design better software systems no matter what language or framework you use. Understanding how they work is crucial to using them well and not taking the pros and cons of these abstractions for granted.Yes, the examples are in C++ and quite old, and I wish they updated this book to implement these patterns in a newer language like Python, Typescript, Go, Carbon, Kotlin, or C#... but even this slight deficiency doesn't justify taking a star away. Every other part of the book is complete gold. It should be updated, but even this version is well-worth the money.

As others have already noted, this is a seminal work on design patterns and is considered by many software professionals as a must read. It is probably a bit too complex for novices to design patterns in which case they are better off using another resource for starters (e.g.: Head First Design Patterns) and then eventually move on to this book. Head First design patterns was obviously easier to read and understand since the examples are more up to date and material is not as thorough as this book. It took me more than a month and half to read this book carefully from cover to cover. Although a lot of the patterns are discussed in depth from a theoretical level including evaluating trade-offs made with specific implementation choices, the examples in SmallTalk are out of date and not that relevant anymore but that's understandable given the publish date of this book (1994). Like some other books (e.g.: Java Concurrency in Practice), multiple readings are necessary to fully digest the material and that needs to be coupled with either independent practice of the specific implementation choices and/or other resources that have more examples of pattern implementations so as to not only reinforce understanding but also lay a solid foundation for Object Oriented Design. Most senior folks working with Object Oriented Systems typically have this book at their desk as a reference. I found one particular pattern, namely Interpreter, pretty difficult to follow. Other than that the rest of the material is readable. Having some familiarity with UML notation will help but the appendix includes explanation of the notation used in the book, so it is not a stopper if you don't have any exposure in that area. Towards the end of each chapter covering a given pattern, the authors include a section on related patterns which can be extremely helpful. This book also organizes different patterns into creational, structural and behavioral categories and also identifies which ones within a given category can supplement each other and which ones compete against each other. This book is not meant to be a comprehensive resource on design patterns and will have to be supplemented by other books. Highly recommended for anyone working with Object Oriented Systems.