Design Patterns

Rating:
Summary: Only if you know C
Review: The book is good if you know C. I only know Java....therefore, the examples were of no use. I found this to be very frustraiting. I really don't konw why it got such a high rating. I bought it for that reason and I wisht that I would have saved my money. If you don't know C, I would not recommend this book.

Rating:
Summary: A good <<Software Development Resource>>
Review: An interesting book for thinkers who are desinging software. Not really for brute force, keyboard bangers. Start using the terms in the book and you lose a few of these kinds of friends. This reference is quite useful, because patterns exsist in designing and programming. Most of the time they are not documented. This work shows how these design patterns interact with each other and how to use them together. There might be some other new or different patterns which resemble or are derived from the foundation laid here. Personally it has help me think and design faster; after a first reading, I found it easier to read through, understand and remember source code written by other programmers. What I can say is that the terminology will sound alien to anyone who has not read the book, but the patterns will be easily recognized by anyone into serious reusable OOP. The botton line is that this book is an asset for any designer, programmer; it helps you to think. You have to read it.

Rating:
Summary: Good concept, good material, hard to read
Review: i think this was the first formal book on software patterns. It's certainly the most popular - every senior object guy i know has this. It has some good material in it, and if you haven't at least memorized the names of the patterns in this book, you might get left out of a few conversations

The one criticism i have is that the authors are clearly not professional writers or teachers. This book is BORING. Really, really boring. It's still a good thing to own, but you ain't gonna read this cover to cover in one sitting and, many times, you'll probably have to steel up your will and tell yourself it's good for you before you crack open the book. It's a good book, but it was written by professional programmers and it shows

Of course, i don't know anyone who took the concepts in this book and wrote something easier to read, so you probably should buy this one

Rating:
Summary: One of the best design books
Review: I felt compelled to reply to one of the reviewers (Geoff Puterbaugh) who gave the book 2 stars based on the fact that certain suggestions by the authors were incorrect. He referred to the "common causes of redesign" section (page 24 in my printing) which the first number was "Creating an object by specification." I agree with the authors. If, in a Java program, the String object is instantiated directly then the using program runs a risk of update in the future if the String class is changed. Yes I know that the chances of that happening are slim in this case, but that is obviously because the String class comes as part of the Java library. You cannot use that as an example to dispute the authenticity of the logic. I do not program in Java but I do not believe that the String class belongs in a class hierarchy that could be changed in the near future. If it did then you are better off not instantiating it directly if you foresee behavioural adaptation for that application in the future.

If, on the other hand, that you design your own class hierarchy, it is good programming practice not to bind user applications directly to any instant of that hierarchy. If you do, you run a risk of updating the application if an upgrade is done on that hierarchy, among other possible changes (and we all should know that changes to code is far from uncommon in most software development environments.)

I work in a financial application software development environment and investment banks & brokerages (amongst other clients) demand quick development of robust and reliable systems. All the software I have come across in my career in this industry have, in one way or another, used these patterns. For anonymous reasons, I cannot name some proprietary products that I have been lucky enough to lend a development hand in, but take it from me that these products have all benefited from this book. And some of the products are used as industry standard applications. I am also not naïve for I believe that there are a few misinterpretations of the way these patterns should be used. I should only hope that the few bad examples would not taint the good ones.

If for no other reason, buy the book for an understanding of OO designs you come across in most software implementation. I am yet to see a system that would not benefit from a Singleton or a Composite pattern.

Rating:
Summary: Brain Opener and Using with No Fear
Review: Truly, after reading this book, you won't ever think about object-oriented design in the same way. (Maybe a little bit exaggerating if you are pattern guru). You would be able to solve specific design problems and make object-oriented designs more flexible, elegant, and ultimately reusable using these patterns. These patterns help designers reuse successful designs by basing new designs on prior experience. The whole design process will be much faster (without reinventing the wheels) and reliable (with proven technique). It also increased common communication ground between designers and developers.

Somebody suggested to use them(the patterns) with caution, and he argued why "everyone seemed to be trying to do EVERYTHING at run-time, and nothing at compile time", the answer here is FLEXIBILITY, EXTENSIBILITY. If you can finish your every task at compiling time and there is no need to interface with other(external) systems and make enhancements(changes), that is great. You gain the performance with "rigid" code. There is really nothing wrong with it. However, in software industry, "Change Request" is its middle name, nothing can be guaranteed but changes. If you bind everything at compile time, you end up with tightly coupled system without any adaptation capability. And the similar situation why "Work was ALWAYS delegated off to some object far far away", and keyword here is DECOUPLING. As to some "13 layer inheritance", that is nothing to do the patterns (I think it is really due to system analysis), actually some patterns will be able to help you to reduce the inheritance tree. I suggest Using these patterns with NO FEAR (If you truly understand what is behind the scence).

Don't be surprised that you can even make client/server (or distributed) system out of these patterns (i.e., Observer (Stock price notification), Command (remote execution), etc.) with minimal efforts, even though the authors claimed these patterns are not for network models.

I believe every designer and developer would benefit from authors' wisdom and insights about OOD with patterns. Please do not argue the sample codes were not in JAVA (EXCEPT you don't know JAVA at all and can not understand what the pattern means, in which case I think it would make this argument self defeated.) It is really the concept that works here not the programming language.

BTW, this review refers to the CD version which works extremely well for cross link(reference).

Rating:
Summary: The Bible of OO Programmers
Review: This book provides a catalog of design patterns and show us how to take the advantage of the patterns.

Patterns are problem/solution pairs, they are comes from the practice of software development. The patterns are valuable and helpful experience of a software engineer.

Rating:
Summary: The Original Design Pattern Bible...
Review: It might not be easy to really make the transition from imperative to object oriented programming, but if you are trying to do this, plan to try to do this, or for whatever are forced to try and do this, you *must* own and have read this book. That's my simple opinion.

For a lot of people this book take as a whole might be a bit to much. After all, its basically an introduction of the concept(s) involved and then 'just' a kind of catalog of OOP design patterns that have proven themselves in multiple practical projects before. The book does not actually take you by the hand and try to teach you something per se. But if OOP is important to you, and even if this book is too much for you at this point in time, I think it best to at least come in contact with it as soon as possible (=now) and keep coming back to it. You will feel the whole concept clicking into place soon enough, especially getting you hands dirty on some practical examples and actually seeing them work and seeing what benefits the use of the design patterns can bring you.

(If you're a VisualBasic programmer, you might benefit a lot from 'Microsoft Visual Basic Design Patterns (Microsoft Professional Series)' by William Stamatakis as well...)

Rating:
Summary: No java? Duh! Check the date!
Review: This remains the best book on patterns. I own many others - and this is the only book that provides clear, concise descriptions and examples. It is an *excellent* book for java developers, too btw - it's the ideas that are important, not the language they are implemented in.

Rating:
Summary: excellent book for programmer who want to learn more
Review: This book is probably the best book talking about OO design. I have been writing java for 2 years, and I have read several pattern books on java. However, none of them can compare favourably with this book. I was truely amazed by this book after i read it.

Be notice that this book is not for beginner, if you are new to OO programming. I prefer you to read some OO book first, otherwise you will find this book too difficult.

The only bad thing , if i have to say, is the sample code is written mainly in C++. For me, a java programmer, who only know java, have to spend more time in it. Besides, some technical aspects like multiple inheritance in Java and C++ are different.

In a nutshell, this is the best book i have ever seen regarding OO design. I recommend this book to anyone who want to write good OO program no matter you use C++ or Java or other programming language.

Rating:
Summary: No Java ?
Review: I was really surprised that the book didn't even has a mention of java.It makes a difference to study OOP design with C++ and java.Since inheritence is more stressed in C++ and Contracts in java.So I couldn't really view the patterns in contracts(java) point of view and the book should have mentioned more on polymorphism in patterns.Here are some books I felt really nice about 1)Java Design --PeterCoad 2)Taming Java Thread --Alen I Holub