Slashdot Mirror
Design Patterns
Introduction
I found the entire introductory section excellent, and a good read. It covers
what design patterns
are and explains how they are documented and categorized. Advice on where
and how to employ design patterns to achieve reusable and flexible software
is also covered to give you an expectation of what you can get out of the rest
of the book. The What, Why, and How are
covered nicely. Even with little previous exposure to patterns, I was able to
understand the presented material easily and begin to see the applications.
Object
Modeling Technique (OMT) notation is also introduced to explain the diagrams
associated with the patterns and examples. If you have used UML,
the diagrams and notations will be familiar to you since UML is influenced by
OMT. Jim Rumbaugh,
the creator of OMT, collaborated with Grady
Booch to create the first version of UML.
As the author notes, having a solid knowledge of OOP is critical to being able to understand and use the information presented. If you don't fully understand OOP, pick up an introductory text first. An Introduction to Object-Oriented Programming by Timothy A. Budd or any similar book will get you up to speed. However, you will get the most out of Design Patterns with hands-on OOP experience.
Case StudyThis chapter presents a case study in designing a WYSIWYG document editor to demonstrate how design patterns can be applied. Most of the examples in the book involve the user interface and I would have liked to see less emphasis on UI models. However, it still gives the reader insight into real applications of patterns. Not only do the authors point out how the pattern applies to each case, but they also present the problems associated with the application. The case study is not intended to set up a perfect example of pattern usage, but to explore it. The reader could go further with the design presented and think about how to solve the flaws pointed out along with the ones that have not been discussed. I liked the fact that they do not attempt to state that there is only one way to solve the problems presented, or that their solutions are even the best way. Too many authors fall into this trap.
Presenting: The PatternsThe three chapters on patterns make up the bulk of the book. The patterns are separated out into the three chapters by type: Creational, Structural, and Behavioral. Each chapter begins with an overview of what the patterns of the type can be used for, and how the chapter deals with the patterns as a group. At the end of each chapter there is a discussion section that summarizes the patterns, along with guidance on how to select the right one from the chapter.
Each pattern description contains a number of sections: Intent, Also Known As, Motivation, Applicability, Structure (in OMT), Participants, Collaborations, Consequences, Implementation, Sample Code, Known Uses, and Related Patterns. The breakdown makes it easy to determine if, why, and how you should use the pattern. The authors are justifiably concerned about using the wrong pattern for a given situation. The code snippets are also easy to work through as long as you know an OOP language. C++ is commonly used, with the occasional bit of Smalltalk code.
The three chapters that detail each pattern would be difficult to read right through. However, the opening and closing section of each chapter has valuable information and is worth reading and subsequently referring to some of the patterns discussed. I got the most out of these chapters by picking patterns that might apply to current projects I was working with and then exploring one in depth, branching over into other patterns in a non-linear fashion.
ConclusionThe closing chapter is relatively short, but makes some important points. The authors discuss what to expect from design patterns, some history and other references/influences. Re-factoring is discussed and how patterns will help mitigate this unavoidable process as the software evolves. Other benefits are also brought up briefly. The book closes with an invitation to give the authors feedback and to find patterns that you use. The best designs will use many design patterns that dovetail and intertwine to produce a greater whole.
Book ExtrasThe whole book has a quality feel to it that is missing from many current texts that cost nearly twice as much. Inside the front cover there is a quick reference to all of the patterns contained in the book with a brief description and page number. The back cover also contains a quick reference for diagram notation and the relationships between the design patters. This is all topped off by two bookmark ribbons attached to the spine.
The Age IssueDesign Patterns was originally published in 1995, and the book mentions that the patterns it contains are little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change. Despite this, since the material is not entirely dependent on a particular language or program it holds up quite well. The examples referred to for each pattern are older software that many will not recognize. An updated version would be nice, but being old does not condemn this book to being useless.
SummaryThis is an excellent book even if it is beginning to show its age. The fact that it's still very useful is testimony to the quality of the material. A few readers might find the reading to be a bit dry, but the straightforward style was refreshing compared to some other texts. The authors stay focused on the topic and condense it appropriately without going off onto long tangents. Once I've followed through with applying some patterns to projects it might garner an even higher rating. Just from reading about some of the patterns, I could see how they could have applied to previous projects I've worked on, both large and small. The book was certainly a worthwhile investment. If a second version of this book ever comes out, I'd be sure to pick it up as well.
Chapters:
1. Introduction
2. A Case Study: Designing a Document Editor
3. Creational Patterns
4. Structural Patterns
5. Behavioral Patterns
6. Conclusion
Appendix:
A. Glossary
B. Guide to Notation
C. Foundation Classes
You can purchase Design Patterns from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Is this book worthy of my money or is it antiquated piece of shit? The author of this review didn't include any sort of this question.
I have only limited funds, and I cant afford something that wont help me. So... all those who bought it, is it WORTH IT?
Thanks.
hehe design patterns remind me of the quote "Those who do not learn from history are doomed to repeat it." or something like that...
if a problem has been solved, and well thought through, the pattern published and peer-reviewed, it probably will hold up for a good long while.
This book is pretty great. It's also pretty dangerous, I've heard of idiots who rate the quality of any potential design by how many patterns it has in it.
Design patterns is important for every OO programmer to read, understand, and hopefully transcend.
This is a fantastic book. It is probably the best book out there for coverage of all of the fundamental design patterns. The examples are in Smalltalk and C++, and are readable and easily translatable to other OO langs (Java, C#, ...).
I would recommend that along with this book, you take a look at Pattern-Oriented System Architecture. It applies the design pattern concept to problems in large scale system architectures.
A combination of the techniques in both of these books can really help unwind alot of the spaghetti problems at both a system and component level. Additionally, alot of the fundamental concepts in modern system architectures become alot clearer once you've read both.
Considering that the book uses pieces that are over 7 years old in a world where technology changes every few months, this review was useful to me - it told me that the information was still useful, valid, and actually might help my programming skills.
So no, I don't believe it was obvious at all - considering that I hadn't even heard of the book until today. (Yes, let the flames commence - I must be a bad, awful programmer because I haven't read some book.)
52 Weeks, 52 Religions with John Hummel
[...] little changed from 1992! In the computer field this would be considered an ancient text with how fast software is updated and languages change.
Holy shit no. 1992 isn't 'ancient' in any way, only for people with very short memory and attention span. Or for people who thinks XML is a neat new idea. Or for people who thinks Java OO-model is a neat new idea. Or for people who thinks Patterns is the new silver bullet. Or for people who thinks Lisp is dead.
Hope you get the idea.
A message from the system administrator: 'I've upped my priority. Now up yours.'
The main good thing about this book is not that it lists a lot of patterns, but rather that it teaches you what a pattern is. This is truly a mind-altering experience. Once you grok the concept, you see patterns pop up all over your own code! Then you can extract and refine their specialties, encapsulate them and re-use them again and again.
This, besides saving you a shitload of future work, teaches you entirely new ways of thinking about object-oriented programming. I've talked to a lot of people who found that reading this book is truly a mind-blowing experience in that respect. Certainly changed my coding.
And the specific patterns in the book are kind of cool, too.
uh, no. Authors of C++ device drivers are not the only "real" coders. I've risen far up the ranks in my career writing database apps with quality, intuitive front ends. My apps are well-designed, have few bugs, and solve numerous tasks that could not have been solved before I wrote them. The end users love me, and I'm well-compensated for what I do. I currently could not (nor wish to) write a low-level C++ device driver. Bleah.
Anyway, if you've got to write a low-level device driver, why are you using C++ at all? Get down to assembly level and do it right!
There are different types of problems out there that need solving. This book addresses ways of solving many of them.
I wish you would have signed this so I would know to never hire you.
Something that you are most likely too young and inexperienced to understand yet is that you do not write code for yourself to maintain. A coder typically writes code and others will maintain it (because you left for another job, got promoted, the project was handed off to a maintenance crew, you got fired for your crappy work, or whatever). THEY have to make sense of your code to fix/maintain it.
If your code is cryptic and/or undocumented, it will cost your company/team lots of time (and time is money) and frustration to debug and/or modify it. Even if you are still in the group, someone else may need to go into the code that you wrote (notice that I did not say "your code" as it is not your code if you are working for a company or contributing to an open software project) to do something. If you routinely contribute such crap to open source projects, you will quickly be denied access to any further projects.
Is it worth it?? Can't say, never read it. But,as an antiquated piece of shit myself that has seen every TNBT (the next big thing) come down the road, it probably was outdated 2 minutes after it hit the news stands, replaced by TNBT.
But, as an antiquated piece of shit who has bought dozens of other TNBT books, it might be worth it. We used to use things called algorithms, and had books written by the thousands with them. I still have a C book on my shelf at work that I reference from time to time because of code segments it has. A good book outlasts TNBT, since they basically all say the same crap. My test is to try and decide if it will make a good reference book, something that will be used every day and can make me an even better haxor than I are now (yes, I meant the poor grammer).
My advice is to get off your lazy geek butt and get thee to a real bookstore, not one of those Internet things. That you can do for free (well, I think you still can, there might be copyright issues). Pick it up and actually read portons of it. Buy it online if you can save a few bucks, or buy it right there if it is so good you can't live without it.
But, for geeks sake man (woman??), make up your own friggen' mind. Make a decision. Stand up for yourself. Don't follow the rest of TNBT sheep. Or go buy the damn thing because they said so, and continue to be an Windows NT programmer. (whoopss..did I say that??)
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
But design patterns also show fundamental flaws in the object-oriented languages: design patterns are abstractions for which object oriented languages have no support. While object oriented languages have support for data structures and encapsulation in the form of type checking and access specifiers, when it comes to design patterns, you have to put them in by hand, document them by hand, and make sure they are working correctly by hand. Design patters are to object oriented languages like nested loops and data structures are to assembly language: you can implement them, but the language isn't going to help. The problem is that object-oriented languages really build abstractions out of individual classes and that individual classes are the units of abstraction and encapsulation, while design patterns require abstraction and type checking at the level of groups of classes. Attempts at supporting design patterns explicitly in object oriented languages so far also have been unsatisfactory as far as I'm concerned.
If you can't imagine any problem in computer science--particularly in the commercial application of computer science--that doesn't need to make use of a relational database, then either you are not trying, or you are experiencing acute myopia. As for the specific example of sorting, I'm sure you've seen some user interfaces that present some sort of data in tabular format. Often in such a UI, the user can click on a column heading to instantly sort the table according to the data in that column. It seems that your approach to implementing this feature would be for the client to request all the data from the database again, this time sorted by a different column. Wouldn't it be more reasonable just to re-sort the same data right in the client application?
Concepts don't fight over territory; people fight over territory. And I'll reiterate yet again: A design pattern is a solution to a problem. Design patterns are used a lot in OO, but they are by no means limited to OO. In fact they're not limited to software at all--design patterns originated with architecture and construction! So if patterns can be applied to building design and OO software design, is it that much of a stretch to say they can be applied to database design?
You want a nontrivial example? OK. Implement an instant messaging application (along the lines of AOL Instant Messenger), including both a server and two clients: a command-line and a GUI version. Clients and servers should communicate with each other using TCP/IP. Use only a relational database to implement the entire system.
It's convenient for the authors to speak in the language of OO because their intended audience is fluent (or at least competent) in the language of OO. If you were to write a book about advanced optimization techniques for relational database applications, I would think your intended audience would have some sort of competency with relational database concepts.
the patterns found in the Gang of Four book for C++ and Java programmers mainly help losers lose less
d s .html
Pandering to 'wannabie elite hackers' is now enough to earn +5 informative? Jesus!
If our Industry cannot develop the tools to move on from a hacking culture to a Proffessional Software Engineering culture, we may as well all give up and go and go back to living in mud huts.
The most simple fact is that Patterns (and the GOF) are to software engineering what Whitworth was to the Industrial Revoulution, the ubiquitous standard that make it possible for a spanner manufactured in Sheffield to tighten a bolt from Africa in a Bridge in Deli.
Try the following for a better insight into the importance of standards in creating a revolution.
http://www.ama-cycle.org/features/whitworth.asp
http://www.wired.com/wired/archive/10.01/standar
---
It's not the ignorance in postings that disappoint it's the ignorant moderation.