What do you think?
Rate this book
Design Patterns: Elements of Reusable Object-Oriented Software
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.
The authors begin by describing what patterns are and how they can help you design object-oriented software. They then go on to systematically name, explain, evaluate, and catalog recurring designs in object-oriented systems. With Design Patterns as your guide, you will learn how these important patterns fit into the software development process, and how you can leverage them to solve your own design problems most efficiently.
The authors begin by describing what patterns are and how they can help you design object-oriented software. They then go on to systematically name, explain, evaluate, and catalog recurring designs in object-oriented systems. With Design Patterns as your guide, you will learn how these important patterns fit into the software development process, and how you can leverage them to solve your own design problems most efficiently.
Each pattern describes the circumstances in which it is applicable, when it can be applied in view of other design constraints, and the consequences and trade-offs of using the pattern within a larger design. All patterns are compiled from real systems and are based on real-world examples. Each pattern also includes code that demonstrates how it may be implemented in object-oriented programming languages like C++ or Smalltalk.
416 pages, Hardcover
First published January 1, 1994
About the author
Erich Gamma
12 books107 followersErich Gamma is a Swiss computer scientist and co-author of the influential software engineering textbook, Design Patterns: Elements of Reusable Object-Oriented Software.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 402 reviews
Read
August 18, 2009Read to understand patterns, but please think for yourself when you code.
April 8, 2008
I know this is an unpopular opinion, but I think the concept of a design pattern is just this side of bogus.
Part of the issue is that the languages the industry has chosen have weak powers of abstraction and thus these patterns seem necessary. Perhaps it's becoming a cliche (or became one 10 years ago?), but I'm sure some haven't yet been exposed to this thought: in a decent language like Lisp, most of these design patterns are trivial. The patterns are only there to make up for the problems with the languages of choice.
For me another issue is that the idea of design patterns is firmly linked in my brain with absurd Java APIs that require me to deal with XYZManagers and ABCHandlers and twenty different classes all for something that anyone sane would have just provided a handful of simple functions for.
On the other hand, this post by Richard Gabriel is interesting:
http://groups.google.com/group/comp.l...
Perhaps design patterns are worth looking into after all, just not in this book.
Part of the issue is that the languages the industry has chosen have weak powers of abstraction and thus these patterns seem necessary. Perhaps it's becoming a cliche (or became one 10 years ago?), but I'm sure some haven't yet been exposed to this thought: in a decent language like Lisp, most of these design patterns are trivial. The patterns are only there to make up for the problems with the languages of choice.
For me another issue is that the idea of design patterns is firmly linked in my brain with absurd Java APIs that require me to deal with XYZManagers and ABCHandlers and twenty different classes all for something that anyone sane would have just provided a handful of simple functions for.
On the other hand, this post by Richard Gabriel is interesting:
http://groups.google.com/group/comp.l...
Perhaps design patterns are worth looking into after all, just not in this book.
June 26, 2019
[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.
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.
November 15, 2010
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.
December 29, 2012
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).
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).
September 19, 2017
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.
June 3, 2007
This is the classic software design patterns book.
Much of this material is assumed knowledge in many development shops so a understanding of this book is very valuable. However, there seems to be a design pattern mania and some developers take the information in this book a bit too literally and assume these patterns are inflexible. The patterns themselves are of value but the bigger take away from this book is how to solve problems with object oriented languages. This is an excellent resource for developers looking to familiarize themselves with common design techniques.
This book verges on being a reference. For more of a guide, check out "Head First Design Patterns" (see my review).
Much of this material is assumed knowledge in many development shops so a understanding of this book is very valuable. However, there seems to be a design pattern mania and some developers take the information in this book a bit too literally and assume these patterns are inflexible. The patterns themselves are of value but the bigger take away from this book is how to solve problems with object oriented languages. This is an excellent resource for developers looking to familiarize themselves with common design techniques.
This book verges on being a reference. For more of a guide, check out "Head First Design Patterns" (see my review).
Read
November 20, 2019Очень полезная и крутая книга, написанная самым ужасным языком, который можно вообразить.
July 7, 2010
I'd recommend this book to any Object-Oriented programmer who wants to be even remotely familiar with the approaches being used to write production systems these days... The Design Pattern based approach to software engineering has definitely caught on, and if you aren't familiar with at least the basic patterns, *you need to be* - not only to they make logical sense, but real development teams use the pattern names often, in discussions amongst multiple developers, to describe the systems/concepts/etc being discussed. If you're not familiar with them, then you'll quickly get lost in the conversation, et al. There are other books on J2EE patterns, or Unit Test Patterns, etc. but, you need to be familiar with the basics first, and *THIS IS THE BOOK* - Commonly reffered to as the GoF (or "Gang of Four") Book, this is one hard cover that you *MUST HAVE ON YOUR BOOKSHELF*, period.
September 16, 2014
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".
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".
August 14, 2008
Ahhhh ... design patterns. Most software engineers have probably used several of the patterns in this book without even realizing it. Still, I found it to be a useful validation of some of my design approaches as well as a valuable resource for streamlining my design. Reading it cover to cover will put any software architect in a position to solve many design issues faster than they may have otherwise.
October 4, 2014
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.
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.
January 3, 2020
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.
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.
September 7, 2022
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.
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.
July 7, 2021
مخاطب
مخاطبین اصلی این کتاب مهندسین نرمافزار و برنامهنویسان هستند. کتاب با آنکه نسبتا قدیمی است اما مرجع اصلی الگوهای طراحی محسوب میشود و اصول مورد استفاده هنوز هم بعد از سالها تغییر نکرده است با اینکه روش پیادهسازی در زبانهای برنامهنویسی نوین دستخوش تغییر شده است.
محتوا
بیست و چهار الگوی طراحی شیگرا در سه دسته رفتاری، ساختاری و ایجادی آموزش داده میشود. الگوی طراحی به معنای ارائه راهحل افراد خبره برای مسائل تکرارشونده در یک زمینه خاص است.
الگوهای رفتاری برای بهبود پویا ارتباطات میان اشیاء طراحی شده است. به طور نمونه الگو دکوراتور در زمان اجرا قابلیت به سیستم اضافه یا کم میکند بدون آنکه لازم باشد در کد نوشته شده از قبل دست برده شود. یک سایت اشتراک فیلم را در نظر بگیرید. بعضی افراد کاربر عادی هستند، بعضی دیگر اشتراک طلایی دارند و از قابلیتهای بیشتری در سیستم میتوانند بهره ببرند. با الگو دکوراتور شما به راحتی میتوانید مشخص کنید که هر قابلیت در اختیار کدام دسته از کاربران قرار بگیرد بدون آن که لازم باشد در کد موجود دست ببرید.
الگوهای ایجادی به ساخت کلاسها و اشیاء کمک میکند. مثلا با الگو بیلدر (builder)
میتوانید اشیاء پیچیده از قطعات ریزدانه بسازید.
و در نهایت الگوهای ساختاری برای بهبود ساختار کد پیشنهاد شده است.
جمعبندی
اگر برنامهنویس هستید لازم است که الگوهای طراحی را بلد باشید. امروزه بدون دانستن الگوهای طراحی مهندس نرمافزار خوبی محسوب نمیشوید.
March 23, 2014
I got this book as part of a job which had me programming in C++. I found it very helpful in understanding how to effectively use C++ so that it didn't kill me. It provides a vocabulary such that you can deal with data in a metalanguage of sorts, at least among colleagues (not in the sense of metaprogramming).
As time has passed, I've looked at Design Patterns in a new way. The introduction to the book is worth a read, even if you don't quite get the significance of it. If people would only take it seriously, I think that people could begin to get an idea of what a science of computing would really be about. I don't say this to mean that what we commonly call OO is the "path to computer science," but the idea of inventing structures that have broad applicability in applications, and to future efforts to invent more varied computational structures.
As time has passed, I've looked at Design Patterns in a new way. The introduction to the book is worth a read, even if you don't quite get the significance of it. If people would only take it seriously, I think that people could begin to get an idea of what a science of computing would really be about. I don't say this to mean that what we commonly call OO is the "path to computer science," but the idea of inventing structures that have broad applicability in applications, and to future efforts to invent more varied computational structures.
July 26, 2020
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.
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.
November 15, 2019
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.
July 9, 2010
This book is a classic, you should read through it and it should sit on your bookshelf. But you should also read something newer and more accessible on design patterns as well, I recommend Head First Design Patterns.
September 6, 2016
It's true that your need for patterns such as these depends heavily on your development stack, but love or hate, use them or don't, I believe it's critical to be familiar with them unless you plan to develop in a silo.
November 24, 2019
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?
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?
February 10, 2018
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.
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.
January 14, 2018
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.
The book is old. You can tell by Smalltalk and C++ examples. But its also a mountain of knowledge.
June 11, 2021
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.
November 1, 2022
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.
October 9, 2019
Впервые все паттерны, собранные в одном месте. Хорошие приемеры, сравнения паттернов и описания их сходств и возможных взаимодействий и "взаимопомощи". Так же можно воспользоваться наглядными примерами на refactoring.guru
December 10, 2020
I had to read it cover to cover, although it took so much time. And it will definitely be a good reference book.
May 26, 2022
It may be a classic, but like many "classics" it was dull and poorly written. My eyes glassed over instantly and I dreaded reading it. I don't think I retained much info. This may be the seminal book on design patterns but there are part better options now days. I recommend "Game Patterns"
June 5, 2023
471-Design Patterns-Erich Gamma-Technology-1994
Barack
2023/06/04
Design Patterns, first published in 1994. It is a software engineering book that describes software design patterns. The book is divided into two parts. The first two chapters explore the capabilities and pitfalls of object-oriented programming, and the remaining chapters describe 23 classic software design patterns. It has had an impact on the field of software engineering and is regarded as an important source of object-oriented design theory and practice.
Erich Gamma was born in 1961 in Zürich, Switzerland. Studied at the University of Zurich. he is Eclipse An expert in Java development editors, he co-authored the JUnit software testing framework with Kent Beck, which helped create test-driven development and influenced the entire software industry. He also led the design of the Java Development Tools (JDT) for the Eclipse platform and participated in the IBM Rational Jazz project. In 2011, he joined the Microsoft Visual Studio team and led a development lab in Zurich, Switzerland that developed the "MMonaco" suite of components for browser-based development that resides in Azure DevOps Services (formerly known as Visual Studio Team Services and Visual Studio Online), Visual Studio Code, Azure Mobile Services, Azure Web Sites, and Office 365 development tools.
Table of Contents
1 Introduction
1.1 What Is a Design Pattern?
1.2 Design Patterns in Smalltalk MVC
1.3 Describing Design Patterns
2 A Case Study: Designing a Document Editor
2.1 Design Problems
2.2 Document Structure
2.3 Formatting
3 Creational Patterns
3.1 Abstract Factory
3.2 Builder
3.3 Factory Methods
4 Structural Patterns
4.1 Adapter
4.2 Bridge
4.3 Composite
5 Behavioral Patterns
5.1 Chain of Responsibility
5.2Command
5.3 Interpreter
6 Conclusion
6.1 What to Expect from Design Patterns
6.2 A Brief History
6.3 The Pattern Community
In the history of the development of computer programming languages, one of the extremely important concepts is object-oriented. "Object-oriented" means that programmers need to think about the system they want to write through a higher level or a more abstract level, thinking about the various objects in the system they want to build so that the system they design has higher scalability. Before we program based on object-oriented thinking, we may write whatever we think of, lacking a main line; but if we adopt object-oriented thinking, then we should actually think about these things before writing the first line of code The game is composed of objects, such as the protagonist, enemies, environment, etc. so that if there are new functions in the future, they can be easily integrated into the existing system. And when we use this way of thinking to design the system more times, we can slowly discover certain laws, these laws emerge, and some common characteristics reflected are what we call design patterns. The so-called design pattern is more of a principle, a feature, and a similarity. It is also abstract rather than strictly defined details.
The author identified many design patterns from the basic framework style of MVC, including observer, composite, and strategy. If we want to describe the design pattern of MVC ourselves, we may be able to make it clear in a few words and feel that this is a very straightforward thing, but this does not mean that we have a deep understanding of the essence of MVC. For example, when the author mentions these design patterns that exist in MVC, I have not thought about them in advance, which means that my understanding of the framework style of MVC is still not deep enough. Whether we are trying to understand framework styles or design patterns, we must have an understanding of the depth of our understanding. Take a new concept and spend a few minutes reading its most basic explanation, and you seem to understand it. This is something everyone can do. When this level of understanding is achieved, it is not really understood. Learning is like this, and so is life. It is very dangerous to think that you have understood everything, but in fact, you only know the surface.
There are thousands of things in the world. Even if we classify it into different patterns and classify different design patterns, there may be dozens of types of design patterns. In order to facilitate understanding, memory, and application, we need to further classify design patterns. For example, we can choose two different classification standards, and each classification standard has three specific values. In this way, we can put these dozens of different design patterns in 9 grids. , the design pattern in each grid may also be a single digit. This way, it is easier to remember. This line of thinking can also be used when we try to understand other concepts that have many possibilities.
The author puts forward some design principles, such as programming for interface rather than for implementation. Design principles or guidelines are highly abstract and can only be abstracted based on the observation of many specific examples. Therefore, no matter any field, if we want to extract our own principles, the first step is to observe many examples; the second step is to find the similarities and differences between these independent examples and seek an understanding of these phenomena. Explanations, these explanations may be lengthy at the beginning, but as our understanding gets deeper and deeper, our explanations may become more and more concise, and in the end, it may be just one sentence. If this sentence is elaborated and can explain most of the instances, then this sentence can be used as a valuable principle. The third step is cross-validation, that is to say, we get the principles from some examples, and then we should verify whether our principles are appropriate from other examples that have not been used. Those who sum up the principles naturally need to have a deep enough understanding of this topic, and the same is true for readers. If they lack a deep understanding, they only see the principle of a sentence, but they cannot understand the meaning of the sentence after it is expanded. If there is no analysis, then we can't really make full use of this principle.
We can divide software into several types, such as application software, toolboxes, or frameworks. The relationship between these three is more abstract than the other, and more general than the other. It is a process from tool to tool making. Their demands on designers should also be increasing. As far as the field of science is concerned, the more abstract concepts we can understand at the level of thinking, the deeper our grasp of concepts will be. From the perspective of expression, the more simply we express the concept, the deeper our understanding of the concept. So there is a saying that if you pass on thousands of volumes of books falsely, but you pass on a single sentence in truth, the thousands of volumes of books may be just an annotation to one sentence. So our learning process is, first read the book from thin to thick, in this process, our understanding of annotations is getting deeper and wider; then we try to read the book from thick to thin, and at that time, we have already understood Notes, you can throw away the notes, and only keep the principle itself.
Doing research, an important part of it is literature research, looking at some of the work that other people have done in the current field. Then, we stand on the basis of our predecessors and do some work further. These works may be to put forward some new viewpoints, or to summarize the old work; we may call the former innovation and the latter literature review. If you want to do a literature review, since there are not many new things proposed, then the most important thing is to do a relatively sufficient investigation of the existing research results, and it is even more necessary to make it clear that the key core point is research. What? Why study this topic? And as researchers, where is the workload generated in this research process reflected?
We use a variety of design patterns, the essential purpose of which is often not to make the current design easier to achieve, but is often based on some non-functional considerations, for example, scalability, which means that the system in the future Can easily add other new features. For example, readability means that the system should be easily understood by others. Without the guidance of a clear design pattern, the way we solve the problem is likely to be taken for granted. As the problem becomes more and more complex, or more and more functions need to be added, we add new functions It will also become more difficult, and the marginal cost is increasing. For another example, maintainability means that if we no longer participate in this project in the future, when others come to take over our project, they can quickly understand our system and know how to modify it. Another feeling is that it is the easiest and the hardest to explain the problem with simple examples. The simplest is because the system itself is simple, so it is easier for the audience to find out what the difference between different design patterns is. The most difficult means that the narrator tries to use different design patterns to design a simple system, which requires the narrator to have a deeper understanding of the core ideas of the design pattern, otherwise, it often stops at the most intuitive design pattern. Therefore, it is very valuable to say that one question has multiple solutions. For the same problem, the more solutions we can adopt, the more we can explain the depth of our understanding.
Read
December 26, 2019One-liner: Read it. 4.5 stars
Displaying 1 - 30 of 402 reviews