I wanted to make use of some of the ideas i learned from this book, but did not work in the kind of programing shop where I could do that. ( )

What the book is about
Have you ever heard of design patterns? These are essential elements of object-oriented programming, and every programmer should know them.
The book will introduce you to this notion of design patterns. You will discover what they are, why every programmer should know them, how they can improve your programming, etc…
Then, the book will cover in a structured way and in detail each of the design patterns.

My thoughts
I think this book is good. But, there is too much information about each of the design patterns. It's impossible to remember everything or to take note of everything.
That's why I see this book more as a cheatsheet, or something you open only when you have a specific need and you want detailed information about something. In this case, if I want information about the Visitor pattern, I just open the book and I will find everything I need.
Also, this book is a lot theoretical. It includes some code examples, but not a lot. This is neither good nor bad because it meets different needs.

Who should read it
I think every programmer who has never heard about design patterns should read it. If you have ever heard of design patterns, it's not so useful to read this book, but it's useful to own it so that if you need information about one design pattern one day you can just find all the information you need in the book. ( )

Great as always.
Very dense, a lot of food for thought. ( )

after A Pattern Language / Christopher Alexander classics

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 am only going to include 10 tech books, a represtative sample]

Compulsary reading. At the time, (when it first came out) this really affected me. I have always thought that IT is a backwards field, compared to making any other objects, and this is the first step in the right direction. ( )

A classic in the field of computer science, this book describes how object-oriented software can be used to develop meaningful (and reusable) classes. It is written by the so-called "gang of four" affiliated with a working group at the University of Illinois. It has achieved notoriety for its assistance in helping programmers write code more effectively in languages like C , SmallTalk, and (my current language) PHP. The book has started a large movement in identifying design principles that are inherent in all computer science problems.

The book reads like a catalog of class types. After an initial critique on the state of computer programming, it reads like a textbook and a reference manual to be used. It is academic, analytical, and brilliant. Obviously, the book is only for the serious programmer who aspires to master her/his trade. It is not for the casual programmer or even for the intermediate programmer. It does not hold the reader's metaphorical hand as the book is perused. Instead, it provides data and analysis like a research paper. Of course, in such a style, wisdom is distilled into compact sentences.

I'll be happy to put this book on my bookshelf at work and refer to it when designing software. ( )

Depending on on how you think of programming, this book could be incredibly insightful, or horribly abstract and impractical. Since I prefer and tend to think in patterns and abstractions, I found this book close to my heart. It uses a variety of languages for examples, so a willingness to explore concepts, not practical solutions, is essential. ( )

It held my interest, but I find it hard to incorporate what seem like very abstract lessons like these into my actual programming practice. I guess I just don't think in OO. ( )

If there were required reading mandated for any degree involving computer software development, this would be it.

Gamma, et al (AKA The Gang of Four) have given us a comprehensive guide to various software patterns, and it's the least we could do to follow them.

It discourages me to see and hear about professional industries making lousy software that can't communicate with other tools, even those made by the same vendor. It bothers me when there are tools out there that make use of a network connection, but apparently don't play nicely with people using other operating systems or even other interfaces. Why can't I play Scrabble on my iPhone with someone using Facebook's Scrabble app? Why can't I play a co-op game of LittleBigPlanet on my PSP with another user playing on a PS3?

Well, the short answer is that you should be able to do these things, using interfacing, one of the fundamental patterns in this book. Just as the user (usually) doesn't care what's going on behind the curtain with their software applications, as long as they get the right feedback when the click the right buttons, the client-side application shouldn't care about what's going on in the server-side, as long as it gets the right feedback from the server when it sends it the right data. When you hear things like this for the first time, it's kind of eye-opening, but at the same time, when you think about it for a minute, it really makes sense. It's like when you're playing a puzzler game, and you need a hint about how to solve a puzzle; once you see the solution, you smack your head. "That's makes so much sense!" you say, "Why didn't I think of that." Well, consider this book the solution guide to software design.

No, it's not a recipe book (like the O'Reilly Cookbook series), but it does provide examples of the patterns you should be using, and unless you describe your coding style as "anarchist," it should really help you.

If you're a software engineer and get your hands dirty by mucking with software, and you haven't yet read this book, then take off those coding gloves and give yourself about a week to absorb the amazing knowledge this book presents. If you want to go into software engineering, ensure that you have a firm grasp of a particular programming language, and then read this book, preferably before you start interviewing for a job. Then, in your interview, when asked a technical question, you can start off your answer by saying, "Well, The Gang of Four said in their book on design patterns..." And then, you're working in some software engineering field (results may vary).

If you're truly devoted to making yourself a better software engineer, though, you simply must read this book. ( )

This book was really a game-changer. The art of creating a computer program had not been analyzed much at all up until that point - plenty of algorithms had been created by computer scientists, and systems designers had some ideas about API's, but there wasn't a whole lot of direction for people who wanted to engineer applications to do things that user wanted them to do. Some of the patterns in the book are in common use today; others have been relegated to the dustbin; but the larger point is that after this book came out, people started using a whole new language to describe the work they were doing. Today we have UI patterns, management patterns, data access patterns, antipatterns, patterns, patterns, patterns everywhere, and this was the book that really caused the concept to take off.

Is it worth reading today? That's a little tougher. There's no question to my mind that every developer should be familiar with the patterns in this book, but a more modern book on the same topic would probably display source code in a language that more people would more commonly be using. Still, there's no question that if you want to go back to the basics, you go back to Gamma. ( )

The software design bible... ( )

The original ( )

A classic for OOP - not much else to say: You've got to read it, if only to say you read it :-) True, the book is C++ focused (it will be somewhat tough for those who only know Java / C#) and it has quite a level of sophistication (probably aimed at those in a Computer Science degree or master's programs). But, that said, it really started a big part of the revolution in OO - open source gave us reusable code, design patterns gave us reusable solutions to design problems; and this was the book that really "lit the fire" for patterns.

Category theory lite for computer programmers.

This book seemed profound when it came out, but has not panned out as a religion. As an isolated analysis technique, it is a great thing; trying to take it further is questionable. ( )

Ein Klassiker, der sich in der Bibliothek jedes Softwareentwicklers finden sollte. ( )

Perhaps more referenced than read...that's certainly the case for me. I've never tried to implement one of these things, but every once and a while I skim the patterns and it's useful to have the ideas filed away. ( )

The software-patterns bible. If you know what patterns are, you should already have read it. ( )

Blech. Rubbish. Compensating for the weaknesses in OO in general and C++ in particular. OO is a nice way to think about some kinds of programming problems, but not all. Patterns are attempts to make OO fit where it doesn't fit naturally. And, in particular, they compensate for C++'s foolish lack of automatic memory management.

Design patterns are getting a lot of attention from both practitioners and researchers these days. This is the book that started it all off. Design patterns are solutions to commonly occurring problems in software development. This book is often referred to as GoF, which stands for "Gang of Four", a reference to the four authors.

The famous book to have a deep explaination to design patterns ( )

Essential ( )

http://malaysianatheist.blogspot.com ( )