Design Patterns: Elements of Reusable Object-Oriented Software by Erich Gamma

Design Patterns: Elements of Reusable Object-Oriented Software Reviews

• 
  Adnan Ali

  Read to understand patterns, but please think for yourself when you code.
• 
  Darcey

  [Note: This is a reference book; I didn't actually read it cover to cover. I did read the first two chapters in full though.]
  
  For the last couple years, I've been working as a software engineer, and I've found myself getting very confused by a lot of our Java code. Why do we use dependency injection? What's a factory and why do we need them? It felt like everyone else on my team had gotten some memo that I didn't receive.
  
  It turns out that everyone else on my team *did* get some memo that I didn't receive, and that memo was this book.
  
  This book describes the concept of design patterns, which are broad overarching ways of structuring your code. Design patterns are not about ensuring syntactic or algorithmic correctness; rather, they're about writing your code in a way that makes it easily extensible, restructurable, and maintainable. A design pattern is not something like "use for-loops for iteration"; that's just a specification of the syntactic structure of the language. And, as far as I understand, "test your code using unit tests" is not a design pattern (since it's not really about code structure), just a good testing practice.
  
  An example of a design pattern is something like using a factory to make new instances of an object. Suppose you have some interface Foo, and an implementation of it called FooImpl. And suppose you frequently need to create new instances of this. You could pepper your code with "Foo foo = new FooImpl()", but then suppose you wrote a new, better implementation of the Foo interface called FooImplImproved or something. You would have to find each instance of "new FooImpl()" and replace it with "new FooImplImproved()". This is a pain. So instead, you could create an object called FooFactory which returns instances of Foo. Then you could do something like "Foo foo = FooFactory.create()". This create() method would then just contain "return new FooImpl()". Then, when you wanted to change FooImpl to FooImplImproved, you would only have to change it in one place: in the FooFactory.create() method.
  
  I think I would have benefited from encountering this book in college, before I ever worked as a professional software engineer. But I wouldn't have fully understood or appreciated it then. I still don't fully understand it, but now that I've worked in industry, I have a much better understanding of the need for maintainable code.
  
  This book definitely changed how I think of programming / software engineering. And, if I'm understanding correctly, back when this book came out, it changed how *everyone* thought about software engineering. As far as I know, this book introduced the concept of a design pattern. The book tells you about all sorts of different design patterns, but I think the main impact of the book was not teaching people individual design patterns, but introducing them to the concept of a design pattern altogether. Once you have that concept, you can identify and use new design patterns more more easily. The specific design patterns presented are certainly useful, but the concept itself is more important.
  
  Also, in the spirit of "reading the history of philosophy backwards", this book taught me a lot about what was known about software engineering back in the early 90s, just based on what it felt like it needed to explain to its audience. One thing that surprised me was that it went out of its way to explain the separation into interface-based inheritance and implementation-based inheritance. I'd always taken that distinction for granted, because it's built into Java, which was my first language. But I realized, after reading this book, that the distinction between implementing an interface and inheriting an implementation was not always obvious. And in C++, that distinction is not a syntactic feature, but merely a design pattern. (Which makes me wonder what it would look like if OO languages incorporated more of these design patterns into their syntax.) Anyway, "program to the interface, not the implementation" was something I had only learned since starting at this job; it's not something that was covered during my undergrad education. So I was glad this book went out of its way to emphasize its importance.
  
  Anyway, this book absolutely gets 5 stars, for introducing me (and also the rest of the software engineering world) to a new conceptual framework that allows software engineers to do a much better job. I expect that I will return to this book very often and will always view it as a useful resource.
• 
  Noah Coad

  A must have primer for any developer working with object oriented code. While it was a decent read from front-to-back (though a bit long), it is even more useful as a reference. Some of the terms are outdated by today's coding conventions, but the principles still apply and it is a fair exercise in mentally converting between the lingo used in the book and what you may be familiar with in C#, Java, or another OOP. One interesting aspect is that you can immediately start to see what programming patterns you're already using today in the frameworks and libraries you may be using on a daily basis. Putting a name to these design patterns, such as Factory, Command, etc helps to identify them and understand them so you as a developer know when best to apply them to your own code. Certainly worth having on any OOP software developer's bookshelf.
• 
  Erika RS

  Design Patterns is a very important reference and its contents are also important, but it is a rather dull book to read. This is mainly because the bulk of the book contains a catalog of patterns. Like most catalogs, it works better when you come to it looking for something specific.
  
  I have two main criticisms of the patterns themselves, both of which stem more from the time the book was written than from any inherent problems with the patterns. First, each pattern contains a list of benefits and consequences. This section never considers the pattern from the view point of testability. This is a pity because most of the patterns, in my opinion, serve to make the relevant components easier to test.
  
  A more serious complaint is that many of the patterns show their age by suggesting implementation inheritance as a good way of implementing these patterns. While implementation inheritance still has its place in the programmer's toolbox, current wisdom shies away from using it merely because it is convenient. Instead, current belief leans more toward preferring interfaces (in the Java sense of only defining operations and not implementations) and reserves implementation inheritance for when it provides a tangible benefit.
  
  That said, most of the patterns still have a useful core, even if some of the details of pattern structure or implementation should be modified to fit better into common practice. Just remember though, if you want to read through it you need will power or a reading group (preferably both).
• 
  Milhouse Van Houten

  Capturing a wealth of experience about the design of object-oriented software, four top-notch designers present a catalog of simple and succinct solutions to commonly occurring design problems. Previously undocumented, these 23 patterns allow designers to create more flexible, elegant, and ultimately reusable designs without having to rediscover the design solutions themselves.
• 
  Julia Roslyakova

  Очень полезная и крутая книга, написанная самым ужасным языком, который можно вообразить.
• 
  Ahmed Salem

  Beautiful Book for very complicated topic for developers and software architects. I liked the first chapter of introduction very much. and one of the best trends I have learned from this book is that, "You don't have to use all design patterns in the software you are making, just use what you think it is useful for the current situation and purpose of the current software you are working on now".
  
  Merged review:
  
  Beautiful Book for very complicated topic for developers and software architects. I liked the first chapter of introduction very much. and one of the best trends I have learned from this book is that, "You don't have to use all design patterns in the software you are making, just use what you think it is useful for the current situation and purpose of the current software you are working on now".
• 
  Selena

  The examples are somewhat out of date. The code can be a bit hard to follow because of this.
  
  Some of the design patterns aren't really design patterns.
  
  You can learn the the basics from this, though, so it's useful. Just be sure to read this with some more knowledgeable programmers so they can explain when the book doesn't.
• 
  Mohammad Shaker

  Probably a fourth read:
  3 stars.
  
  First Read:
  5 stars. Although an old one, it's a very good book. Maybe the best on design patterns. The joy you feel when you read it and discover that you have implemented the solution by yourself before is really enriching.
• 
  Paul Sochiera

  Exceptional book that
  a) introduces many general key fundamental OOP principles in its opening part and
  b) later goes on to describe OOP core design patterns in a well structured manner
  
  I would deem it as an essential.
• 
  Alireza Aghamohammadi

  
  مخاطب
  
  مخاطبین اصلی این کتاب مهندسین نرم‌افزار و برنامه‌نویسان هستند. کتاب با آنکه نسبتا قدیمی است اما مرجع اصلی الگوهای طراحی محسوب می‌شود و اصول مورد استفاده هنوز هم بعد از سال‌ها تغییر نکرده است با اینکه روش پیاده‌سازی در زبان‌های برنامه‌نویسی نوین دستخوش تغییر شده است.
  
  محتوا
  بیست و چهار الگوی طراحی شی‌گرا در سه دسته رفتاری، ساختاری و ایجادی آمو��ش داده می‌شود. الگوی طراحی به معنای ارائه راه‌حل افراد خبره برای مسائل تکرارشونده در یک زمینه خاص است.
  
  الگوهای رفتاری برای بهبود پویا ارتباطات میان اشیاء طراحی شده است. به طور نمونه الگو دکوراتور در زمان اجرا قابلیت به سیستم اضافه یا کم می‌کند بدون آنکه لازم باشد در کد نوشته شده از قبل دست برده شود. یک سایت اشتراک فیلم را در نظر بگیرید. بعضی افراد کاربر عادی هستند، بعضی دیگر اشتراک طلایی دارند و از قابلیت‌های بیشتری در سیستم می‌توانند بهره ببرند. با الگو دکوراتور شما به راحتی می‌توانید مشخص کنید که هر قابلیت در اختیار کدام دسته از کاربران قرار بگیرد بدون آن که لازم باشد در کد موجود دست ببرید.
  
  الگوهای ایجادی به ساخت کلاس‌ها و اشیاء کمک می‌کند. مثلا با الگو بیلدر (builder)
  می‌توانید اشیاء پیچیده از قطعات ریزدانه بسازید.
  
  و در نهایت الگوهای ساختاری برای بهبود ساختار کد پیشنهاد شده است.
  
  جمع‌بندی
  
  اگر برنامه‌نویس هستید لازم است که الگوهای طراحی را بلد باشید. امروزه بدون دانستن الگوهای طراحی مهندس نرم‌افزار خوبی محسوب نمی‌شوید.
  

  
  
• 
  Matthew

  A classic.
  I first read this book a decade or two ago, and I recently got feedback that I should read it again. It's nice to be more experienced and have more perspective on the text, instead of just taking everything as is. Some of the patterns (like Builder and Observer) I've seen used countless times. Other patterns, like Memento and Mediator, I've never seen in the real world.
  If you're serious about software engineering read this book.
  
  I wouldn't recommend this book for beginners - you should have a few years experience with at least one programming language, preferably something compiled like C/C++/Java.
• 
  Louise

  I go back and reread sections of this book or skim it when I’m trying to think of a way to architect something. It’s pretty dry and the language the examples are in aren’t one that I typically use but easy enough to follow along. The diagrams are harder to get the hang of but otherwise, one of the must reads for anyone writing software.
• 
  Ľuboš Barskto

  Klasika softveroveho inzinierstva. Kniha ktorej obsah by mal ovladat kazdy objektovo orientovany programator.
  
  Kniha bola vo vseobecnosti dobra, bolo tam viac menej vsetko co som od nej ocakaval. Miestami sa trochu opakoval dej a bolo tam privela hlavnych postav, a na konci som uz aj tak vedel kto je vrah. Pri niektorych vzoroch som mal pocit, ze mohli byt lepsie vysvetlene (napr Flyweight). Takisto boli podla mna vzory State a Strategy slabo opisane v zmysle ich odlisnosti, pretoze z knihy som mal pocit, ze ich implementacia je totozna, iba sa pouzivaju na iny ucel, co ale nie je uplne tak. Trochu zamrzelo prezentovanie moznosti implementacie niektorych vzorov v jazyku Smalltalk (co je pre mna neznamy jazyk) a uplna absencia implementacie v Jave (co je pre mna zase naopak primarny jazyk).
  
  Ucebnice sa tazko hodnotia, obzvlast asi take ktore predbieha ich povest. Navyse, kto hlada najde a kto chce vediet, tak sa nauci bars aj zo zlej ucebnice. Je moja chyba ze som nepochopil vsetkemu na prvy krat alebo to mohlo byt napisane lepsie?
• 
  Andrej

  I've consulted this book on several occasions in my career, but never really read it from beginning to the end.
  It's certainly an old one - 1994 (and therefore the code examples are not all that consistent with the modern trends ex. Smalltalk), and in something as fast evolving like software engineering this one is still more than relevant and go-to book for many experienced engineers.
  
  Should be considered in every advanced object-oriented and even general software engineering course in colleges everywhere.
• 
  Michał Niczyporuk

  This is a goodbook. Not an easy read, but definitely worth it for junior/mid-level OO developer. Every design pattern is explained thoroughly, and there are even 'consequences' sections on every one, and one connecting described pattern to other patterns. If you study every pattern you will get a mountain of knowledge.
  The book is old. You can tell by Smalltalk and C++ examples. But its also a mountain of knowledge.
  
• 
  Aaron

  An excellent survey of useful design patterns for object oriented design in software. Although a little dated with reference to technologies and languages (who uses Smalltalk still?), the core ideas and concepts are still very important in 2021’s software engineering world as well.
• 
  Diep Dao

  A classic book for application class-level patterns, but I would recommend reading this book after you have some years of experiences in software engineer as it may be hard to understand the abstract concepts.
• 
  Leonora Minton

  One-liner: Read it. 4.5 stars
• 
  Francesco Abeni

  This is definitely a book worth reading.
  
  The most difficult thing in it is not to understand the patterns themselves, but the underlying object-oriented knowledge. In other words: you won't understand patterns if you don't understand object-oriented programming. So, in some ways, this book will teach you OOP even more than it will teach you patterns.
  
  Another drawback is in the examples. There's been a huge evolution since the book was written, and the current web applications are quite different from the 1990-1995 programs that the book uses as real-life cases. Some of those examples may not so immediate for a 2013 web developer.
  
  That said, reading this book is still - in my opinion - a mandatory step on the way of any developer enlightenment.