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 books114 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 415 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).
May 2, 2024
Սա էլ շարունակությունը։
Շատ չոր մասնագիտական շարադրանք ունի։ Եթե այս գրքով որոշես սովորել նախագծման ձևանմուշները, ուրեմն 99%֊ով հիասթափվելու ես, ու գիրքը փակես դնես կողքի։
Այս գիրքը պետք է կարդալ, եթե արդեն գաղափար ունես, գիտես ինչ է design pattern-ը, բայց ուզում ես ավելի խորը ուսումնասիրել։ Այ էս դեպքում գիրքը իսկական հրաշք է։
Ամենակարևորներից է, որ գիրքը շատ լավ ստրուկտուրավորված է, բոլոր ձևանմուշները կան, ինչպես նաև ամեն մեկի առավելություն, թերություն, դասակարգում...
Ու այս ամեն ինչի շնորհիվ 2 ձևանմուշ միմյանց հետ համեմատելը շատ հեշտ է դառնում։
Նույն ձևանմուշը Head First-ից, հետո այս գրքից կարդում ես, ու վերջ, դու ամեն ինչ հասկացար։😎
Օրինակներն էլ C++ են։
Շատ չոր մասնագիտական շարադրանք ունի։ Եթե այս գրքով որոշես սովորել նախագծման ձևանմուշները, ուրեմն 99%֊ով հիասթափվելու ես, ու գիրքը փակես դնես կողքի։
Այս գիրքը պետք է կարդալ, եթե արդեն գաղափար ունես, գիտես ինչ է design pattern-ը, բայց ուզում ես ավելի խորը ուսումնասիրել։ Այ էս դեպքում գիրքը իսկական հրաշք է։
Ամենակարևորներից է, որ գիրքը շատ լավ ստրուկտուրավորված է, բոլոր ձևանմուշները կան, ինչպես նաև ամեն մեկի առավելություն, թերություն, դասակարգում...
Ու այս ամեն ինչի շնորհիվ 2 ձևանմուշ միմյանց հետ համեմատելը շատ հեշտ է դառնում։
Նույն ձևանմուշը Head First-ից, հետո այս գրքից կարդում ես, ու վերջ, դու ամեն ինչ հասկացար։😎
Օրինակներն էլ C++ են։
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 7, 2023
Sometimes I am curious about what percentage of people who recommend/ praise/ preach about certain IT/computer science-related books have read them fully :) My impression: far from 100%
This book is very famous and influential. It aims to show the best solutions to common problems in software development (mostly in object-oriented programming). We have Creational, Structural and Behavioral design patterns (self-explanatory) that are the best tactics in certain situations (solo or combined). And, oh boy, there are many design patterns. Very often they are rather similar to each other and to do things even worse: a pattern with the same name may fall into different categories. o.O
I tried not to skip what I could not comprehend well, so sometimes I re-read the same paragraphs many times. It seemed that I understood things about the patterns but after finishing the book I am confused more than ever :D It wasn't helpful that code examples were in C++ which I don't care to learn any time soon. I'm glad I took notes - without them, I'd be completely lost.
Don't get me wrong: the design patterns are often very pretty and elegant (and those folks who "invented" them are totally smart!); it may save a lot of time because reduces the need for refactoring; also the book itself is well-structured and not bad... Still, I was brute-forcing my reading journey :D Finishing it became my self-serving goal because after a while I understood that the knowledge won't stick for long. Probably I'll be using the Singleton and a few others (the most simple ones) 90% of my coding :D
Was it worth it? Not sure, probably spending this time on coding would be more useful...Still, I decided to challenge myself and read one IT book a month (btw, I read this since the end of August). And building habits is important in the long run.
This book is very famous and influential. It aims to show the best solutions to common problems in software development (mostly in object-oriented programming). We have Creational, Structural and Behavioral design patterns (self-explanatory) that are the best tactics in certain situations (solo or combined). And, oh boy, there are many design patterns. Very often they are rather similar to each other and to do things even worse: a pattern with the same name may fall into different categories. o.O
I tried not to skip what I could not comprehend well, so sometimes I re-read the same paragraphs many times. It seemed that I understood things about the patterns but after finishing the book I am confused more than ever :D It wasn't helpful that code examples were in C++ which I don't care to learn any time soon. I'm glad I took notes - without them, I'd be completely lost.
Don't get me wrong: the design patterns are often very pretty and elegant (and those folks who "invented" them are totally smart!); it may save a lot of time because reduces the need for refactoring; also the book itself is well-structured and not bad... Still, I was brute-forcing my reading journey :D Finishing it became my self-serving goal because after a while I understood that the knowledge won't stick for long. Probably I'll be using the Singleton and a few others (the most simple ones) 90% of my coding :D
Was it worth it? Not sure, probably spending this time on coding would be more useful...Still, I decided to challenge myself and read one IT book a month (btw, I read this since the end of August). And building habits is important in the long run.
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.
December 8, 2023
Finally read this cover to cover. Design patterns seem to be a lost art around me. I knew some of them but it was good to learn about Proxy/Decorator/Builder in their more general (perhaps original) sense. A lot of them relate to UI systems though. Hope this will help me think about refactoring more actively. Amazing technical writing as you would expect.
Also discovered this gem while googling: https://python-patterns.guide/
Also discovered this gem while googling: https://python-patterns.guide/
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.
Displaying 1 - 30 of 415 reviews