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.
For a second there I thought it said designing patents. I guess that's what happens when you spend more time reading /. than doing your actual programming work. :)
"Son, in a sporting event, it's not whether you win or lose, it's how drunk you get" - Homer J. Simpson
This book IS the definitive word on the use of patterns, I have used it and will vouch for it.
However, for all the knowledge it contains it has a price tag to match. If you can get it used and cheap, do so.
AC
This book was published what, 8 years ago !
/. at the leading edge as usual.
Nice to see
Actually I sort of doubt that.
To ensure perfect aim, shoot first and call whatever you hit the target
I have never seen a code monkey in a well designed patterned outfit. I wonder if this book will help at all.
---
When you come to a fork in the road, take it! --Yogi Berra--
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.
Can we get a review of this site, slashdot.org I've heard so much about?
Sorry, I'd just thought everyone had heard about Design Patterns long ago. Seems a bit like publishing a book review on the KJV Bible or something.
If you go into any room up in Waterloo and mention "Design Patterns", everybody in that rooms knows exactly what you're talking about. Its one of the Classic books around here. Expensive, runs about $75-$100 Canadian. Hard to find a used copy. And never in at the library.
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.
Maybe overusing isn't the correct term, but definitely blindly using. I have seen far too many times (in far too short a time) where people will just start tossing in as many "patterns" as they can.
Sometimes, as if to really horrify me, the reasons for including a pattern are to appease a manager!! This really frightens me, as the patterns are not discussed at the planning stage, but as an afterthought to implementation.
Which brings me to a question. I have always viewed design patterns to be something that are used during the planning phase of a project. All too often, I am seeing where people start trying to shoehorn a design pattern into a project because they just heard about how great of a job it does at something. Does this happen elsewhere, or just with the projects I see?
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.
Even with no exposure to patterns, I was easily able to understand this book. This book was my first exposure to patterns, and I don't think I could have had a better introduction to the subject. I highly recommend this book to anyone who knows anything about object-oriented design.
The sort of people who read these books are the sort who normally couldn't code their way out of a paper bag. Ask them to write a low level device driver or network protocol and they'll piss their pants , but ask them to write some high level description of some GUI front end using as many buzzwords as they can shoehorn into the design document and they're in their element. And this is one of the books they'd have sitting on their shelf. Its a comfort blanket for people who kid themselves they're programmers but in reality are designers who should never be let near any C++ compiler. Is it any wonder with modern day management trumpeting this kind of rubbish that afar greater percentage of IT projects overrun, are overbudget and don't meet the spec than ever before?
They seem overly complex, and although they try to be general, I can't imagine that they could be easily adapted to any but a few (large) software projects. I don't have enough good examples, but I get the feeling that every major software project will come up with its own "design patterns", and they probably bear little resemblance to the ones in the book (and will be a lot simpler as well). My wife likes them, and she thinks that they provide a common vocabulary for developers to use in developing their own patterns, although I am not convinced.
What has been the experience of /.ers who actually use this book in their (non-educational) software development projects?
"Overhead, without any fuss, the stars were going out."
Most of the stuff in the design patterns book was interesting to look at 5 years ago when the book first came out.
You would be better off now to read through the JAVA class documents.
Design Patterns that are published in a book like that lag the real practices of the software industry by many years.
Folks who work in software lead the industry, they don't live in the publishing houses or in the ivy covered hallways of money mongering corporate universitys.
Ya, That book was cool a few years ago. Now it is OUT OF DATE. Don't pay full price for that one.
What the review missed to point out (okay, I only gave it a once over..) is one very important aspect about patterns and this book in particular; it gives developer a new common language to use when communicating about software design.
For instance, you might have 're-discovered' the visitor pattern yourself and used it several times, but without the nomenclature of this book it was very hard to actually talk about that design with other developers.
Great book, one of few that - after reading it - got me all exited about development again.
Belief is the currency of delusion.
wtf?
If you read Design Patterns, the next book to read should be AnitPatterns: Refactoring Software, Architectures, and Projects in Crisis (ISBN: 0471197130). Design patterns shows you what to do, Anitpatterns shows you what *not* to do (and how to fix it if its already fscked up).
HTTP/1.1 200 OK Date: Tue, 05 Nov 2002 15:53:22 GMT Server: Apache/1.3.26 (Unix) mod_gzip/1.3.19.1a mod_perl/1.27 mod_ssl/2.8.10 OpenSSL/0.9.6g X-Powered-By: Slash 2.003000 Connection: close Transfer-Encoding: chunked Content-Type: text/html; charset=iso-8859-1
For java developers I would strongly recommend reading this book in conjunction with Sun's applied Java patterns book.
bn.com actually beats out Amazon by $10.
Design Patterns[associate] is $54.99. Compared to $44.95 at bn.com.
Go ahead and click on Slashdots link.
Most of that stuff in that book is trivial.
Anyone who does real development was using these patterns years before the book came out.
Books like these are catelogs of other people's ideas and put into a standard format. It is like saying that noone could breath oxygen before the perodic table of the elements came out. Obviously oxygen was around for ever. The patterns in this book are DESCRIPTIONS of other peoples work. It was the method of presenting the ideas that seemed new at the time.
But when it comes right down to it JAVA or C++ classes do a much better job of documenting good design patterns for programming.
The idea of Design Patterns is probably something developed by patent mongerers. They take very simple and trivial ideas and make them seem important by putting them in a common format. Big deal.
You'd be better off reading working code than wasting your time on a five year old book that documents 15 year old ideas.
The book is worth looking at, but both it and design patterns as a whole are nothing much. It's hard to push through design patterns books, because most of the patterns will be familar to you already if you've done some design and/or used various frameworks and toolkits. The innovation of the design patterns book/movement is simply to give names to common design elements so they can be discussed. This is useful, but not a breakthrough of any sort.
Book reviews!
Where else can I get unbiased reviews of the latest programming techniques?
Outstanding job Taco! Keep up the good work!
[...] 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.'
good book for a highschool programmer to breeze through in a few minutes.
Better, start cutting code and see what actually works. Pretty headers and large fonts with the name of some trivial idea don't cut it in my world.
I want CODE that WORKS. Not some big thick and EXPENSIVE book.
I do like this book, but be honest, it is OUT OF DATE and NOT cutting edge at all.
The Demo design pattern:
Boss: We need to have a working demo by the trade show next month.
Developer: OK, but it's just going to be a barely working hack. There's no time to do any proper design by the show. It's going to push back the ship date because we're going to have to rip out the kludges and redo them properly.
Boss: Fine. Just get me that demo.
The Ship date design pattern:
Boss: We need to ship the product by the middle of next quarter.
Developer: We don't have time to fix the demo hacks by then. We need more time to do a proper design. I told you that the ship date would be pushed back by the demo.
Boss: Everybody saw it working at the show, and they wonder why they can't have it now. We have to go with whatever you've got.
The Beeper Design pattern:
Boss: Support has been getting a lot of calls from customers in the field. A lot of random crashes. We need to have a developer available 24x7 to help debug these problems. Here, take this beeper.
Developer: I told you so.
Boss: We need to get a demo of version 2.0 by the field sales seminar next month.
Developer: Aaarrghhh!
Have a look at Best Book Buys. They've got pricing for most books both new and used. Searching for Design Patterns currently shows a book for $35 used and $45 new.
LOAD "SIG",8,1
LOADING...
READY.
RUN
I'll vouch for the book. It was one of the textbooks from a Programming Languages and Paradigms class that I took. The first 2/3 of the class was advanced Java topics, but it became significantly more interesting when we dove into design patterns.
Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, a.k.a. The Gang of Four, did an excellent job. If you don't buy it, at least pick up a copy at Borders and skim it. You will be a better programmer for it.
Here's another good breakdown of the book
I've been programmin in various compiled & scripting languages for about 5 years now. I still consider myself a beginner because I have zero formal training even though programming is my career.
Considering that I have zero formal CompSci training, is Design Patterns a good purchase for me?
After reading the Gang of Four book, I picked up "The Design Patterns Smalltalk Companion" (the book at Amazon). It explains how to apply each design pattern in Smalltalk.
I found it invaluable to be able to see the same patterns discussed and implemented in a languate different than those I normally use. Each language has its own strengths, weaknesses, and best uses. The Smalltalk Companion helps you think about how your favorite language works.
Transcript show: self sigs atRandom.
I see a problem because younger people tend to ignore books because they are old. I recently talked to a (20ish) manager who spoke like he never read The Mythical Man Month or Debugging the Development Process. It was like he really believed that a 80 hour work weeks and more programmers would bring the project in on time.
As has been viciously shown over the past couple years, fundamentals don't change just because someone rewrites a book. It is precisely those books that prove to be fundamental, those books that do not need to be updated every few years, that provide a person with a basis of knowledge.
"She's a scientist and a lesbian. She's not going to let it slide." Orphan Black
Read the book, because it's good. Lots of it will make obvious sense. Use that stuff. Some of it will seem like a stretch. "You're calling that a pattern?" Don't use that stuff.
Programming is about basic principles applied intelligently. If it's complex, it's probably not right. You have to sift through the ideas of the week, such as template-, OO-, component-, and pattern-based programming, to find the right way to solve a particular problem.
The design pattersn book contains 23 patterns. It is a sign of it's greatness that since then, patterns have become a hot topic, but no-one has been able to produce a list of another 23 generic patterns as widely applicable.
In other words: You're wrong. They got most of them.
Having said that, some of these 23 are more common than others. Particularly I have coded/seen/used these ones: Abstract factory, Factory method, Singleton, Adapter, Proxy, Iterator, Observer, Visitor.
The most common of these are becoming ubquitous. Have you never used a single instance of a global var? that's a singleton, almost, and it's a good idea to go the whole hog and enforce uniqueness. Most langauges handle DB recordsets with an iterator or something very like it. Event multicast is the observer pattern.
It is possible to overuse/abuse patterns. I've seen code where a 'designer' has latched onto the 'abstract factory' pattern and used it as a 'golden hammer' (See Antipatterns - another fine book mentioned in other posts here)
My Karma: ran over your Dogma
StrawberryFrog
You sir, should be beaten soundly with a nice big thick document. As a sysadmin I cannot recall how many times I've run across mindless fecal matter such as yourself. Documentation is a key element in any piece of software, be it a shell script or a complex application. It gives maintainers something to look at to get up to speed and provides everyone who uses your software a reference from where they can start.
If you want to be an elitist prick who sits in a cubicle all day and writes code. Fine. Just remember that nobody in your office actually likes you and they all talk about what a prick you are behind your back. After a few years you will wonder why people who are your junior are now managing you. Keep pondering that and eventually you might become enlightened.
Good day.
Which, I think, is actually a problem with
the way some people think, to my great annoyance -
is that now every problem has to be thought
of only in terms of one of these patterns,
and [your favorite deity or lack thereof] forbid
you actually come up with something new...
Considered harmful.
Design Patterns are important because they suggest that Software Engineering might actually have some content beyond regular CompSci courses.
My school has Bachelor's degrees in both CompSci and Software Design the primary difference being that Software Design students are required to take all the Software Engineering courses while CompSci students get to choose. There was a heated discussion at a recent Dept. meeting over whether CompSci students should be allowed to take the full-credit capstone project in Software Design; it was decided that they should only be allowed to do a half-credit project: "otherwise there'll be nothing to differentiate the Software Design degree".
Now Software Engineers can sit around and learn various patterns for four years, which is exactly what industry wants them to be doing. After all, with a 4-year degree you should be an architect managing diploma-holding-code-monkeys rather than actually writing code yourself. Computer Scientists will have no use for such courses, pointing out that they've had their own "patterns" all along: they're called "algorithms".
Design patterns is the distillation and categorization of the most useful kinds of objects. Should be required in any computer curriculum.
I own this book and have found it to be a valuable resource when designing a system. I've used it only for small backend applications though the concepts are even more appropriate for larger ones.
Damn right! My copy of 'Design Patterns' has sticky notes sprouting out of it all over, coffee stains and every other indication that it is something I use all the time.
Let me point out that I have owned the book since it came out and have already been through the 'Maybe this *is* a silver bullet.' stage to arrive the 'No silver bullet, but damn useful.'
What are design patterns good for? Well, certainly not slavish adherence to a particular way of doing things. However just about every pattern in the book (and others discovered since) is really something a good programmer knows already. But the book provides a shorthand 'language' and nomenclature for discussing object designs.
And the use of patterns has some emergent qualities as well. Sometimes thinking about your designs in this way allows you to more easily see connections, opportunities and traps you might otherwise have missed...
Jack William Bell
- -
Are you an SF Fan? Are you a Tru-Fan?
Design patterns are an attempt to sidestep experience. It's like trying to learn to drive by only reading a book. For some reason, all the good coders I meet never talk about design patterns, and all the bad ones, well... do.
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.
That simply isn't a strong enough statement. If you're doing object oriented programming, you owe it to yourself to at least borrow a copy to read.
Design Patterns is not about telling you how to program. It's about discovering that lots of random, unrelated things you've been doing for years are actually related. It's about building a common language with other programmers about things you're already doing instinctively. The book starts by explaining that the patterns weren't created, they were discovered. Once they began looking for patterns, they found them everywhere. And when you see the patterns, you'll often go "Hey, I've been doing that for years, but I never really thought about it!" The book is about stepping back a bit from your work to discover patterns you've overlooked even as you implemented them. The perspective on other similar projects and teh analysis of common uses will help you apply solutions you already know to new problems. This is a great book.
Search 2010 Gen Con events
Richard Gabriel thinks design patterns are important, but he also believes that the patterns found in the Gang of Four book for C++ and Java programmers mainly help losers lose less.
"Design Patterns" really is an excellent text that everybody doing OO design/programming should read.
While you're at it, pick up the books that inspired the idea of "design patterns" for OO design: Christopher Alexander et.al.'s books on architecture, especially A Timeless Way of Building (introduction to the idea of patterns) and A Pattern Language: Towns, Buildings, Construction, which contains their pattern catalogue (there's a third one in the series which I haven't read yet that describes the application of some of the patterns in a real-world example). Both books are beautifully written, accessible to non-architects, and (interestingly enough) seem to be more popular with computer science people than with architects.Back to the CS design patterns, the reason why most of the examples draw on UI techniques probably stems from the fact that most patterns result from the author's work on the ET++ framework, which was quite popular in the early 90's (one of the first integrated software development tools for C++, SNiFF, was build with it -- very nice software before it became yet another commercialized packaged bloatware thingy.)
I guess it's a repositioning of "Slashdot: News for Nerds" to "Slashdot: Stuff for People."
"Slashdot: News for Nerds. Stuff that matters." I take this to mean that all articles SHOULD match either "News for Nerds" or "Stuff that matters" or both. This article apparently matches the latter.
You may find the following pages of links interesting as well:
We don't need Disney to find Nemo
Will I retire or break 10K?
I went to look at other recent slashdot reviews to see what other books design patterns compares to. The results are hilarious:
I think that we should have a way to vote reviews "fair, underrated, or overrated" (and have that change the ranking) because it is clear that books with limited applicability (some only a blip on the technology horizon) often get rated better than truly groundbreaking pieces.
Pattern Name: Wait Until it is a Fad
...
Intent: A programmer finally gets a clue that there is something to design patterns
Also Known As: Hello World Pattern
Motivation: A programmer continually hears the phrase "Singleton Patterns are for dummies" from his collegues, thus feelling much less than a dummy
come on fhqwhgads
Will anyone who has bought and used the CD version comment on it? I'd be particulary interested in usabillity and the rumored "addtional content".
~~ What's stopping you?
Apart from highly recommending the GOF book I'll like to point your attention at the online Java companion to the book.
http://www.patterndepot.com/put/8/JavaPatterns.htm
Actually the companion can be read without the book (for those on a budget).
Cheers, John
TCAP-Abort
An alternative to designing software using patterns is to refactor code toward patterns.
This is considered one of the best ways to use patterns by many in the patterns community -- especially to avoid the "little boy with a pattern" syndrome described by many here.
For more on this idea, and on patterns in general check out the Portland Patterns Repository. There is also a conference every year about patterns called PLOP
Finally, the software patterns community owes its origins to the Architectural (think buildings not code) Patterns world. Christopher Alexander is considered the father of patterns. His books A Timeless Way of Building, and A Pattern Language are technical, dry and expensive, but considered fundamental to truly grokking patterns.
We are agents of the free
http://directory.google.com/Top/Computers/Programm ing/Methodologies/Patterns_and_Anti-Patterns/
also check out amazon.com's used books and lists from other programmers including:
Applied Java Patterns by Stephen A. Stelting, Olav Maassen
Pattern Languages of Program Design (series)
Pattern-Oriented Software Architecture (series)
Design Patterns Java Workbook by Steven John Metsker
Design Patterns Explained: A New Perspective on Object-Oriented Design by Alan Shalloway, James R. Trott
Concurrent Programming in Java(TM): Design Principles and Patterns (2nd Edition) by Doug Lea
Pattern Hatching: Design Patterns Applied (Software Patterns Series) by John Vlissides
... but this book is a excellent documentation for Fresco (formerly known as Berlin).
Sorry, coudln't resist, feel free to mod me down.
Regards,
Tobias
Regards, Tobias
I heard recently in a talk (by Craig Larman) that it was Kent Beck of Extreme Programming fame, and not the Gang of Four, who originally came up with the idea of applying Christopher Alexander's "pattern" concept to software engineering.
Can anyone confirm or deny that?
Of course even if that is the case, the G4 deserve very much credit for taking the idea into so much depth. But in fact like many other people, I had believed that it was Erich Gamma of the Gang in particular who had developed the concept.
Always keep a sapphire in your mind
High pattern density shows that the engineer anctualy sat down and thought about design. Most /. kiddies are apt to sit down and start banging code without any design though at all.
A system showing high density will, by defenition, be better designed that one without.
--
You sure got a purty mouth...
I've never heard of MVP, but the book makes mention of a very classic pattern: MVC (Model-View-Controller). MVC is actually heavily used in Java web development as an architecture for developing the front tier. Generally, when you hit the site, a master Controller uses CGI parameters or the request URI or both to dispatch to a sub-Controller which handles that specific type of request. The Controller is responsible for collecting data into a Model, which is basically one or more Java objects, and putting that into a request object (or session). Model objects are generally relatively dumb data-containing objects, sometimes called JDO (Java Data Objects) or JavaBeans. JDO are more focused on getting stuff out of a persistant store. The Controller then hands that Model off to a View, which is generally a JSP (or ASP, or whatever). The idea is that, given a different parameter, the Controller could hand that same model off to a different View - say you wanted to generate a page for a wireless device, just dispatch to the wireless View.
This pattern is more of an architectural design pattern, whereas this book focuses mainly on object model design patterns. But the MVC model is actually used heavily today. Check out Struts, which is quickly becoming a standard framework for web application development.
MFC also has some MVC in it, but they call their Model a "Document", and their Controller an "Application." Check out MSDN.
-If
Run a pencil-and-paper RPG campaign with your far-off friends: Gametable!
Suppose I want to implement my own Iterator rather than relying on STL. The idea that there should be a collection object and a separate "cursor" object to point into the collection object is good. I then look at their example. The collection is a linear list which which exposes a public reference to GetItemAtIndex(i). All the cursor object does is keep a private copy of int i and does a GetNextItem() by i++ and calling GetItemAtIndex(i) on the collection.
Ok, ok, they need a simple example to show the basic concept. But if a collection has a GetItemAtIndex(int i) method, I fail to see why I need the cursor object except as a wrapper around an int i. To me, the Iterator pattern is interesting if the collection is implemented as a linked list and if GetNextItem() actually interacts with the collection on the level of traversing the list.
So the Iterator pattern needs to give the cursor access to some of the non-public workings of the collection, so as to not break encapsulation of the collection while making the cursor efficient in its access. A Google on Java Iterator turns up the use of inner classes on the collection to do just that. I didn't find anything C++ specific, but I imagine that the cursor could be a friend class to the collection class.
I would like to see some more concrete examples on how to implement GoF in both C++ and in Java that solves some of the technical details of how to pull these patterns off. Yes, I know about C++ friend and Java inner classes, but I would like to see the GoF show what implementations they have in mind and to comment on usage of, say C++ friend declaration, in terms of advantages and pitfalls in terms of the degree of coupling between cursor and collection and what are good design practices in terms of trading off efficiency for encapsulation.
GoF is good at the conceptual level but weak at the concrete level.
Design Patterns is about teaching idiots how to think.
Here's an Alternative:
Look through all the code you have written over the years. See what worked and what didn't. Look for the structures and approaches you used intuitively and pragmatically. Find places where you almost had a good design but it got too complicated or went off on the wrong track. Find places where a simple idea that really works is buried under a lot of complexity. See if you can find any recurring themes. Keep all of this in mind for the future.
Review scores are almost completely meaningless. You're comparing a single point of information from several different reviewers on several different subjects. This further dilutes any value remaining in the number.
how to invest, a novice's guide
It is not just in designing OO code that you need some knowledge of patterns. You need to know about patterns to understand existing code.
A number of frameworks and libraries are have been designed using the patterns in this book. Understanding patterns helps understand what the library designer was trying to achieve and how to use it effectively.
For example the decorator pattern is essential for understanding java.io library. (Okay you can understand the java.io library and have never heard of this pattern - but you would have needed to grasp the general concept even if you don't know the standard name for it)
Personally, I think the book does read like it was written by a committee - there are a lot better writers on programming out there. But it is invaluable in OOP world.
GOF (Gamma, et. al.) Patterns show a primary flaw in much of OO philosophy IMO. The equivalent "patterns" in a procedural/relational (p/r) approach will typically involve roughly 80 percent relational query(s). IOW, "formulas" instead of "patterns". Formulas are not only more compact, but don't clutter up the larger-scale structure of the code. (LISP fans say similar things about GOF patterns, I would note).
The "noun model" is mostly via the database in p/r, and is "virtual" rather than a physical code structure. GOF patterns thus look primitive, or "pre-virtual". Database designers in looking for common threads to managing noun models, discovered "pattern formulas" in the form of query languages, especially relational query languages.
OO structures like those found in this book tend to reinvent incremental parts of database techniques from scratch each time. The programmer has to hand weave most of the interrelations and "indexing" between classes. The result is similar to the "network databases" that fell out of favor in the 1960's. The GOF Patterns movement is mostly a rehash of technology and philosophy that died in the early 70's, as variations of Codd's relational model proved superior.
Thus, you are not only reinventing a (halfass) database with GOF, but reinventing an out-of-style one on top of that. A double-whammy no-no in my book.
Dare I say "Disco Patterns"?
If one understands how to use relational databases and technology properly, their need for GOF Patterns greatly diminishes IMO. I know I will take lots of heat for this, but it is what I believe. (Some niches may vary due to special requirements or equipment limitations. But I would note that 1980-era lite-duty DB's ran in like 64K.)
(Is it just me, or is slashdot having network difficulties today? This is the 3rd repost try.)
Table-ized A.I.
Pick up a copy of Martin Fowler's Refactoring too. The reviewed text and this one transcend any particular language and get down to the fundamental concepts underlying the code. These are the real how-to books that go beyond syntax.
Brevity is the soul of wit
-- Polonius
pointing out that they've had their own "patterns" all along: they're called "algorithms".
This harks again to a question of definitions. What is the difference between:
1. Patterns
2. Algorithms
3. Formulas
Different design methodologies and languages will implement that same thing with different arrangments of these three. (FP and relational will tend to use formula-like thingies instead of class-like structures to represent the GOF patterns, for example.)
It might help clear up some hype and flame-wars if there were agreed-upon definitions of each of these.
Table-ized A.I.
One guy who has done a lot with this is Joshua Kerievsky. He has a good guide to study patterens on his site, and has made a start at a book which makes patterns fit into the overall development process as part of the refactoring phase. I've gone through it once, and wil be the first to admin it needs some copy editing, but the idea is sound. Anyone interested can check it out at
http://www.industriallogic.com/xp/refactoring/
Check out the rest of the IL site as well, as there are good resources there.
Open Source Identity Management: FreeIPA.org
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.
http://directory.google.com/Top/Computers/Programm ing/Methodologies/Patterns_and_Anti-Patterns/
also check out amazon.com's used books and lists from other programmers including:
Applied Java Patterns by Stephen A. Stelting, Olav Maassen
Pattern Languages of Program Design (series)
Pattern-Oriented Software Architecture (series)
Design Patterns Java Workbook by Steven John Metsker
Design Patterns Explained: A New Perspective on Object-Oriented Design by Alan Shalloway, James R. Trott
Concurrent Programming in Java(TM): Design Principles and Patterns (2nd Edition) by Doug Lea
Pattern Hatching: Design Patterns Applied (Software Patterns Series) by John Vlissides
Actually, the way it is written, it clearly means that "News for Nerds" is "Stuff that matters."
A deep unwavering belief is a sure sign you're missing something...
Dominus gave a hilarious and insightful talk at YAPC 2002 about Design Patterns, titled, Design Patterns Aren't.
Become a FSF associate member before the low #s are used
Martin Fowler also recently released another patterns book dealing with enterprise patterns called Patterns of Enterprise Architecture.
Another site mentioned by Martin Fowler is Enterprise Integration Patterns. This site deals with patterns found when creating distributed enterprise systems.
A very few principles can replace many 'patterns'. For instance, loosely-coupled designs are a good thing because they are easier to change, extend and modify. Loose coupling can often be achieved using indirection. Indirection can be realized using inheritance, functional abstractions hiding data, and even sometimes as simple a thing as a pointer-to-a-pointer. Each language offers different facilities for indirection.
Giving these few basic ideas 20 different names, as does the GOF book, really doesn't add much value. If you get the basic idea (indirection is good) you can invent these and many other 'patterns' at will, and will be a much better developer than someone who has 'learned patterns'.
Beware also that the term patterns implies much more universality than they deliver - use a different/more powerful language and you may find that many of the 'patterns' become unnecessary or irrelevant.
The principles above (loose coupling and indirection are good) are here to stay. If you must read the book, try to focus on the similarities between the patterns.
Most developers would be better served studying a programming language significantly different from the one they use than studying 'patterns'.
A lot has happened within the field of patterns since 1995.
9 6, 0201607344,00.htmld emic/product/1,4096, 0201895277,00.htmld emic/product/1,4096, 0201310112,00.html
Each year there is seven patterns conferences held around the world. At each of them 15-50 patterns or pattern languages are workshopped and published in book form. Got to http://www.hillside.net/ and click on "conferences" to learn more of the conferences.
The form has evolved a lot since the Gang of Four book was published. Pick up the proceedings for a recent patterns conference to see for your self.
The largest repository of patterns are the proceedings for all these conferences. Unfortunately they can be very hard to get hold of unless you attended the conference at which the pattern you are interested in were workshopped or can borrow the proceedings from someone who attended.
There is a set of four books published by Addison Wesley and easily obtainable, that are a collection of the best patterns from the first four years of these conferences.
http://www.aw.com/catalog/academic/product/1,40
http://www.aw.com/catalog/aca
http://www.aw.com/catalog/aca
In one of the posts above someone asked if the "Design Patterns" book was obsolete by now, because it is seven years old. Patterns are solutions to problems that arises again and again, and for which there is a solution that has been succesfully used in several independent cases. So patterns are in starch contrast to the API of the month phenomenon.
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.
Design Patterns may be one of those books that is useful to people in different ways at different stages in their career.
I read it a couple of months ago, during a holiday in Ireland with my family (who mocked me righteously for doing so). Absorbing the book away from a computer screen is not a bad idea, since one of the ways it can be useful is as an aid to consolidating the things you've been learning about programming during the six months you just spent chained to a keyboard.
I expect to return to it again soon, this time as a reference. A lot of the GoF patterns don't really fly in Visual Basic, which is what I use at work - Singleton for instance just degenerates into Global Variable, its evil twin. But I'm certainly seeing the merits of object composition, not least because implementation inheritance has to be done through delegation in VB6 anyway.
The extent to which a more experienced coder will find such a tome useful probably depends on that individual's propensity for holistic thinking. If you spend all your time rooting around among the trees, the aerial view of the wood may surprise you. Others may have been in the habit of drawing patterns out of their own experience for years; even so, it can be good to see them named and catalogued, and to have a common terminology for communicating with others about them.
Experience is a hard school, but fools will learn no other.
First of all, as to whether a book like this could even be considered "antiquated": In construction, a door is a design pattern. A window is a design pattern. A stairway is a design pattern. (A design pattern, after all, is just a solution for a problem in a particular context, with a particular set of consequences.) Even though construction techniques have certainly changed over the centuries, many of the common design patterns used in construction haven't changed all that much, if at all. I expect the situation to be the same for software, at least until there is a fundamental shift in the way programming is done.
Second, the authors of this book don't claim to have invented the patterns described within. They merely organized and catalogued a number of design patterns that were already in common use, formalizing their definition. The result is a lexicon of sorts, one that is useful not only as a reference, but (as many others have pointed out numerous times) because it provides the beginnings of a common vernacular in which developers may speak. I recently heard an analogy that works very well: a dovetail joint in carpentry. If, in communicating the design of a cabinet, a carpenter had to describe the mechanics of the dovetail joint to other carpenters, the communication would be inefficient to say the least. But, because of a common vernacular between carpenters, the term dovetail joint carries with it a specific context and a solution. Likewise, if I were to, for example, use the term strategy pattern in a conversation with other developers, it's obviously more efficient if they're familiar with the term than if I have to explain it. Gamma et al have already done the elaboration of most of the common design patterns.
Finally, note that I used the phrase "common design patterns"--this book isn't meant to be an exhaustive lexicon of design patterns; I'm sure that would be quite impossible. Rather, it describes many of the common ones (as well as some that aren't so common). There is no implication that, "If it's not in here, it's not a design pattern." Clearly, many other design patterns exist, as there are many problems in many contexts out there to be solved. Already we see books that present technology-specific design patterns (Core J2EE Patterns by Alur et al is an example of a collection of design patterns that generally make sense only within the context of J2EE.) So Design Patterns is not intended to be a canonical reference either. It's just a starting point.
So what is this book good for? First, it reasonably explains what design patterns are all about. (Obviously, other books do this as well; one that I like is Design Patterns Explained by Shalloway and Trott.) Second, and perhaps more importantly, the book provides an extensive (although not exhaustive lexicon of concepts, many of which are (or should be) universally used. I wouldn't say that every developer ought to be intimately familiar with every pattern described herein, but probably half of them should be in just about every developer's vocabulary. If it's useful to have this "dictionary" of design patterns on your bookshelf, then you'll probably find this book to be of value. If you already have access to design pattern references (on the Web, perhaps), then maybe you don't need this one as well.
A bit dry? Old? Hmmm. These are logical patterns. It's about as likely that they will become obsolete in a decade as say the conditional of predicate logic will! Hmmm, first order logic...formal "and" and "or", uh oh, it's over 2000 years old, it's starting to show it's age! We need something new!
I know the review is positive, but I just couldn't avoid the new-is-better fallacy of that writing. To use a pattern or not, that's a question whose answer might change, but the only thing that would make Design Patterns obsolete is... well, nothing, the patterns could have errors, that's all. That doesn't mean they are the best solution to a given problem... but they are not presented as that. They are presented as logical abstractions for certain systems and they will always be logical abstraction for certain systems! They even mention that some of their patterns are not the efficient or best way to make the system under consideration (e.g. parsers), just like using logic isn't always the best way to make a compelling argument... but the logic does not thereby become obsolete!
-pyrrho
Tablizer has some strong views on programming languages, which can generally be summed up as something like "databases are a programming language; all other languages are inferior to databases" [1]. For more details, feel free to try and twist your brain around his article on Table Oriented Programming.
His intellectual hostility towards anything except his own ideas (and object oriented programming in particular) is fairly well known, and been discussed to death on /. before. In short, this is a fellow who has ver likely never really bothered to try to understand design patterns, nor any other OOP concept, beyond the point of mastering whatever jargon he needs to start arguing his pet theory that databases are a superior programming language.
Tabilizer would do well to remember Carl Sagan's quote about genius...[1] For the record, this is my own summary of his position, not his own words.
I'm a computer science student at the University of Waterloo who is taking courses in software engineering. The one that I'm taking right now mentions that Design Patterns is an optional textbook, but the professor (Andrew Malton, for those UW students who've heard of him) highly recommends this book. It seemed that in his opinion, it shouldn't be optional. He actually told us to get it. And he taught us using examples from the textbook. So for those of you saying it should be used as a textbook, I have good news. It is.
Is a new edition with Java code snippets likely?
For instance, you might have 're-discovered' the visitor pattern yourself and used it several times
No thanks. Once was enough for me. Visitor is a tangled mess. It sent me on a google hunt for alternative perspectives. Eye op3ner best ever. This pattern thing is bunk.
But... but... this is GOD'S book. GOD wrote it. Wouldn't GOD know that the kidneys weren't the seat of all emotion? Why would the eternal wisdom of the bible be subject to imperfection via humans? Is God not powerful enough to force his only book to be accurate?
(though he'd probably get a lot of flak from ppl for making use of it, even though it is a legitimate referral. :P)
No argument required.
The GOF book is great, no questions. When I
was a C++ programmer, it was my bible.
When I switched to Lisp, I discovered I didn't
seem to need most patterns anymore. Seems I'm not
the only one to have made this discovery; a well
known lisp expert, Peter Norvig, shows us why
half the patters in the GOF book are not required
in more powerful languages: http://www.norvig.com/design-patterns/
The upshot is that most patterns are required
because of C++'s lack of powerful abstraction
facilities.
That's a good example, because it's another area where many commonly used languages fall short. Languages should support the abstraction of control structures, but most object oriented languages don't. This is indeed just as much of a deficiency in widely used OOLs as their lack of support for design patterns.
You're saying "walls are nice, but the problem with bricks is that they don't come pre-built into walls."
And that's probably why bricks aren't used that much anymore: in order to lower the cost of construction and improve its consistency, many walls these days are, effectively, created "pre-built".
I think perhaps you (and the AC who responded to the same post) have misread this post. While it was written in a flamey style, my take is that it's written by someone who has been there and done that plenty of times.
Look at the two big things that he (I assume) says.
Personally, I think there's a lot of truth in both of those. I disagree with his take on design patterns, in that I do value and use them. Then again, I've seen plenty of people who tried to work them into a design "just because". They are truly and completely missing the point of patterns. I'd rather work with someone who didn't see the point and avoided them than someone overly clever who tried to use them without a good reason.
Further, many (most?) managers are among the worst people in this respect. If you don't produce your 1,000 pages of buzzword-laden documentation this year, you're obviously not working hard enough. (These are the same people who judge productivity by how many lines of code you write per day.) It's a sadly overlooked truth that your code really should need little paper documentation if it's done properly, and the best low-level documentation -- indeed probably the only worthwhile low-level documentation -- is the code itself. Just follow some simple basic steps:
At this point, your paper documentation should be limited to something like:
Everything else really is just waste paper, yet how many projects have you seen where they print out what every single function does and file it away, even though 99% of it will be redundant next week since we changed everything? I have watched projects collapse under the weight of unhelpful or downright obstructive paperwork and procedures, and seen the light. :-)
So seriously, while this guy comes across as flamebait, just stop and ask yourself whether he's really a pimply 15-year-old L337 Hax0r, or whether he's a 20-year veteran who's seen it all before and knows that at the end of the day, working code and lightweight procedures are worth far more than any management buzzwords and formal process certifications you care to mention.
Of course, he could still be a 15-year-old s'kiddie, too. If he is, though, I think he writes with more than a slight ring of truth.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
...is the sound of a hundred /.ers picking up the GOF book and thumbing to page 18.
Oh, and he's right, by the way. :-)
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I can see where you're coming from, and I certainly agree with the "blind use" problem. On the other hand, I think design patterns are useful in two ways.
While the latter is hardly an afterthought, it's definitely not the (initial) planning stage. As you implement a design, and discover which bits work and which don't in practice, that design evolves. I find design patterns quite useful as a way to guide that evolution: maybe something you planned one way didn't work, but it's naturally tending towards some standard idiom and you just didn't realise it yet.
If anything, I'd say this is actually more useful than having the patterns to hand during initial planning, when you don't really know how things are going to turn out. If you look for patterns (and not just the ones listed in the GoF book!) constantly during your adjustments, you naturally tend towards cleaner, more consistent designs.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
For a more beautiful insight into the history and need for patterns in design (whether software or buildings), read the book that started it all.
The Timeless Way of Building by Christopher Alexander
Oxford University Press; ISBN: 0195024028; (1979)
Perhaps that text is more interesting to those of us who were flip-flopping between the School of Architecture and Institute of Technology back in college, but it's also good for the Renaissance Man in you.
I agree that it's nice when high level languages support common programming idioms. I agree that a "for each" construct, and indeed list-based data structures in general, are often tidier than the equivalent "for loop" and array-based data structures. However, while Dominus has a good point here, he's downright misleading at times.
To use his own example, Perl's "universal" solution to iteration -- the foreach concept -- isn't. It's very elegant in the trivial case, when you want to process the entirety of a single list. However, suppose your data is in some non-list-like format, or you don't want to iterate forwards over everything. Then your data first needs converting into a suitable list. With the Iterator pattern, the logic to do this is encapsulated in its own class. With foreach, you have to provide a suitable conversion function. But the code to do it is still there. Using foreach simply replaces one idiom with another equivalent idiom.
Other styles of programming language each have their own answer to this. In a functional language, you would typically provide high level functions to iterate over your data structures, effectively replacing the foreach statement with a set of customised statements, each with a certain type of iteration built-in. Of course, now the logic that was in the iterator class or the list-producing function has to go in the high-level function instead.
One could certainly argue that the foreach approach (and the accompanying use of list-based data structures, to give credit where it's due) is more elegant than the use of iterators, though clearly it also has downsides (ahem, performance issues). One could definitely argue that the higher-level function approach is more powerful than either of the above. But I think it's rather unfair to imply that they somehow remove the need to provide whatever underlying logic you need for your iteration. The examples given in this presentation show a biased case, where the iterator approach offers no benefits over a simple for loop, and the foreach construct is simplicity itself, but it ain't necessarily so under other circumstances.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
An oldie but goodie. Contains the full original canon, with great lines like 'The LORD ith my thepherd' (Book of Pthalms, err, Psalms) and 'Blessed are they which do hunger and thirst after righteousness: for they shall be filled.' (Book of Matt) and my personal favorite, 'Behold!' (throughout).
If you get the hardbound edition it gives a place for all your children to sign when they get baptized (or leave a baby footprint). And the full text is available online since Britain isn't under the Bono Act.
POOP Patterns produce programming that is pounds of putrefied pasta such that nobody wants to reuse such crap even if they could. LISP Rulz. Java and Gammaetal is for PHB lemming lemons. Some of us know better. Hate to sound arrogant, but it is the truth.
A vibrant field? Sounds stagnant to me. How many patterns could you possibly come up with?
The middle mind speaks!
Quote:[Sorry, I'd just thought everyone had heard about Design Patterns long ago.]
Get of your high horse dude.
You may have heard of design patterns
I may have heard of design patterns.
My Mom has never heard of a design Pattern.
Many First and Second Year CS Students have never heard of a design pattern.
Just cause you are smarter than god doesn't mean every one else is.
--meh--
After hearing about how great a book this was for months after its initial release--from both good and bad programmers--I thought it would be worth looking into. So I picked up a copy and flipped through it, mainly hitting the patterns themselves.
What I found was there were a lot of abstract design ideas that now have names, which I suppose is a good thing. I was dissatisfied, however, with the quality of the content. A lot of the patterns were bad designs, and I didn't see any admonitions like 'you should never use this except in this very narrow case XYZ, where you don't have any control over the code to redesign it properly (3rd party libs) and it must exhibit ABC properties', but should have been. Just presenting designs with names is like loading a gun with multicolored bullets and handing it to a child.
After discussing the book with many co-workers, I noticed the trend that the programmers who tended to be more methodical and thorough in their up-front design, disliked the book, because it gave them no new ideas to work with, and introduced a number of useless designs on equal footing with the good ones. However, the programmers that were most scatterbrained and tended to play fast and loose with OOD and data flow, loved the book because it gave them a definitive reference for what to call the messes they create, without making judgements on their codepiles.
I'm not saying that it's a bad book, but I am saying it appeals to a crowd that needs that kind of book. Unfortunately, no book can teach Good Design. That author would be rich indeed.
Any connection between your reality and mine is purely coincidental.
The best design for a given problem is the least conceptually complex one.
If I can satisfy the requirements of a problem with 2 patterns, that is better than using say 7 objects.
The rationale behind this is the more items need to be implemented the longer it takes. More importantly the number of opportunities for bugs as the result of getting the interaction between two objects wrong rises quadratically.
By contrast using the two patterns an experienced coder will have to deal with two items, the coder is already familiar with, which then need combining.
The notion of simplicity also describes how 'throwing in a few patterns' makes a design worse. If you are so inclined, maybe, you could develop a more formal weighting model assinging difficulty factors to a simple object (1), a composite pattern (2), an association class (3).
Of course 'the pointy haired boss' has a tradition to reward complex solutions, which may be measured in terms of the number of patterns, objects, or even lines of code.
Sorry, but that's silly.
This is such a important book, because it contains fundamental stuff, that doesn't change every year.
For instance, you might have 're-discovered' the visitor pattern yourself and used it several times, but without the nomenclature of this book it was very hard to actually talk about that design with other developers.
The flip side of this is that the code you wrote to access your database used to log web site vistors confuses the hell out of the same developers when they see your "Visitor" object..
Seriously, the number of times I've chosen a class name for perfectly good reasons only to find out it conflicts with a design pattern name is frustratingly large.
It gets to the stage where whole swathes of the English language have been removed from the programming namespace by the people who write pattern books.
Patterns are great in their place, but we are in danger of having too many and they can't solve all the world's problems. Stop creating more patterns and using up more valuable English words before all my variables and classes become "flirble", "glarble" and "dooberry"..!!
Q.
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.
Design Patterns have 2 useful qualities, IMHO:
- it provides a shared language to talk about design at a somewhat more abstract level than individual classes from the problem/solution domains
- most of the patterns in the GoF book are aimed at reducing coupling between/cohesion within modules
Its the second of these that helps to make code more maintainable, because it means that changes don't have to propagate wildly throughout the system.However, you still need to write terse, elegant code with terse, meaningful comments for others to navigate your code, whether you use design patterns or not.
they deal with gluing objects and GUI's together which, granted, is an important task for many apps, but not for solving basic computational problems.
Whilst about a third of the patterns are structural that leaves two thirds that are not, they are creational and behavioural patterns. The GUI examples are just that examples, they are not the only application of those patterns. Indeed that assertion alone implied your have missed the point of patterns. A pattern represents a standardised solution for a recuring problem, problems that occur again and again. A good approach is to learn and always consider the pattern in its abstract form.
So for example, consider the composite pattern (GOF:163), the example is based on the relationship between a number of GUI controls. i.e. Point, Line, Polygone etc. However the same pattern can also be used for a B-tree, a directory, a master-detail structure, a relational database, a menu structure, a DOM, an XML document. Indeed it represents a good solution for structuring all these requirements. In its abstract form the composite pattern can be used to implement any example of nested nodes and leafs.
You don't need trees much? Presumably you also don't need hash tables, or graph structures either?
Thank you, Mr Tabilizer. You have just proved beyond all doubt my long-held belief: your views don't work for most programmers because in your world, you only need one type of data structure, a database table, while those of us in most domains need a little more than that, and the tools to manipulate them.
That would explain an awful lot about why you see so little value in many OO concepts.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
This is exactly the problem with Tabilizer's arguments. I've worked him out now. ;-)
His only experience is with low performance databases. He uses terms like "custom biz apps", but this is what he means. Unsurprisingly, in this particular field, tools designed specifically for the job (databases) tend to be more applicable than general purpose programming tools.
Unfortunately, due to his lack of outside experience, he fails to appreciate the vast number of other programming fields, many of which need rather better control over things. By his own admission elsewhere in this discussion, he doesn't see much use of tree structures, which tells you a lot. After a few of us started throwing back not just anecdotes but real world examples where databases just don't cut it -- your instant messaging application being another one -- he started adding this disclaimer you've seen: now he's only referring to his "niche", and not any others, all the time, and OMMV.
He also has an irritating habit of reducing anything he hasn't seen personally to anecdotal evidence. I actually worked on a large (1M+ LOC) project that was essentially an OO rewrite of an old procedural app, moving to a new platform. In spite of having a smaller team to develop it and having only two domain specialists available instead of the dozens when it was first written, we managed to exceed the functionality and reliability that the original had after around 100 man-years of development, by clearly and objectively defined criteria on which the continued funding of the project depended, and we did it in about 25 man-years.
Presumably, this was entirely down to the stunning increase in in the ability of the newer development team compared to the older. The past experience also helped us more than we were hindered by having to work out most of the low level protocols and firmware idiosyncrasies from scratch because the documentation had long since been lost. None of it had anything to do with one being written in C using purely procedural techniques, and the other being written in C++ and making use of OO, though.
Now, to me, this is as close as you're ever realistically going to get to seeing the same thing developed with and without OO to compare them. Yet, apparently, it's just another unsupported anecdote. He wants to see the code. What does he expect, for me to give him 1M+ lines of my employer's copyrighted source code? What would he do with it anyway, spend the same six months as the rest of us learning it so that he could try to pick holes in the OO model (which, clearly, worked quite well for us most of the time)?
Now me, I'm quite prepared to accept that when you're programming database apps, a database is the way to go. I just happen to find OO useful in programming instrument control apps that interface with external hardware, embedded control software, games, high performance mathematical code, system tools, and communications software, all of which I've worked on in the past.
OO is no panacea, but like many other developers out there, I find it helps to organise larger applications in my niches (plural). The reason Tabilizer gets so frustrated is that he's quite short-sighted, and while he may expect and demand that the rest of the world show him some sort of evidence of OO's superiority that meets impossible criteria, vast numbers of us have seen it for ourselves and made up our own minds from personal experience. He's not going to convince us we're wrong by telling us that all our anecdotes (which we happen to know are true ourselves) aren't good enough for him.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
But they do not necessarily represent the same information. They have different structures that provide different behaviour. You require different basic operations to hold on a key or value type to use it in a binary search tree compared to a hash table, for instance. To add data to a hash table, you require a definition for a hashing function on the keys. To add data to a binary search tree, the keys must support a suitable ordering relation.
Further, trees have wider uses beyond storing key-value pairs for fast look up as well. As naturally recursive data structures, they provide a clean and easily manipulataed representation of many things: the results of parsing text representing regular expressions or mathematical formulae come to mind.
Just as importantly, different data structures have different performance characteristics. A balanced tree can provide O(log N) insertion, deletion and searching. A hash table typically provides amortized constant time operations, but in the worst case is O(N).
Consider graphs, a common structure in much mathematical work. There are two major data structures used to represent a graph: adjacency matrices and adjacency lists. Each has its uses, and offers different performance trade-offs. You simply have to understand your data, and the ways you want to access it, in order to decide which data structure(s) are most appropriate to represent it.
It is mathematically impossible to achieve all of the optimal performance characteristics from conflicting data structures without any of the downsides. It cannot be done. You are telling me that you want to swap between all the different approaches at will, but in doing so, you ask the provably impossible. I am telling you that the approach you have with a database is a compromise, a good one perhaps, but still a suboptimal solution for most problems, and one over which you lack the fine control to make it optimal. Sometimes, that's good enough. For many applications, of the type I write, it is so far from optimal that it is not a practical solution to the problems I need to solve.
Oh, and the customary answer to your question about storing data in multiple places, by the way, is simply to store the data nodes in some central structure and then store some form of reference, pointer, or index to them in your various look-up structures. I'm sure you're thinking that sounds like a database, but to the rest of us, that's a rather grand title and it's really just data structures 101. We still do it in one line of code, and ours runs a hell of a lot faster than your generic database look-up algorithms do.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Now that I have to take issue with. There are, as we have demonstrated in this thread and elsewhere, numerous fields where databases simply aren't a useful programming tool. There are very few fields where OO is not applicable if you choose to use it, though there may be specialist tools that would do the job better. (What are those tools written in, though?)
I don't really want to get into this whole argument all over again, but just consider: I could sit down, right now, with your typical OO development system, and write you a database (either an actual DBMS or a custom biz app based on a database), and I could do this without using any Oracle, MySQL, or whatever. I can therefore do anything a database can, though perhaps not as cleanly until I've built the tools to reinvent a database.
On the other hand, I rather suspect that you couldn't sit down with your typical database package, right now, and write me an OO compiler. In fact, I rather suspect that you couldn't sit down with your typical database package, right now, and write any of the applications I've ever worked on.
This in itself should tell you something about the relative expressive power of the two approaches, and how general-purpose they really are.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.