I have some questions regarding design pattern (DP) usage, in particular for Java developers.
i) Which DPs have you used, as far as you can remember, and how often?
ii) How much have they helped your development work?
iii) If you work in a project group, are there group standards for architectural and design pattern usage?
iv) How can patterns be used more beneficially?
v) Did you (or your group) get design pattern training?
Thanks for your contribution.
MVC, Listener/Observer - all the time. They're essential for Jave UI work.
Thanks. Can you comment on any of the other questions?
ii) They are absolutely essential
iii) not recently in a "project group"
iv) ?
v) yes, but in the early 1990's when they were a new idea, so more conceptual than specific.
Thanks again. We think they are very important too. So are researching ways to make them easier to understand and use, especially new comers to the industry.
In my opinion the Head First Design Patterns book is a pretty good and understandable introduction to design patterns. I believe good examples of how design patterns can be applied are key to making them easier to understand for newcomers. Also I'd recommend to clearly demonstrate the benefit of applying the design pattern over another possible approach for a specific scenario. Also a list of advantages / disadvantages per pattern can be helpful.
wrong questions, useless answers.
You use what pattern, if any, is applicable to the situation at hand. Just because some pattern is "popular" doesn't mean it's "better", let alone universally superior to everything else.
I've worked on applications where the designer/lead programmer was a pattern fanatic and dedicated to using a specific pattern everywhere, mindlessly.
All such were characterised by being bloated, poorly designed, under performing, maintenance nightmares.
Determine what your overall application structure should be based on its functional and technical infrastructure requirements, then and only then start thinking about how to engineer that application, and patterns will emerge as a matter of course out of that. Starting with a pattern and thinking "oh, how shall I make a multiuser distributed document management system using an abstract factory" isn't the way to go, it's the way to disaster.
Maybe a bit overtstated but...
I certainly agree that patterns are a tool to use where, and only where, it's appropriate to use them. And that follows from the requirements and constraints, it should never precede them. Patterns are "recommended" solutions to common design/code problems - so until you know what the problem is you can't begin to chose patterns.
Problem is that too many folks jump directly to patterns without understanding how the code looks without them or facing the problems first hand. The line of thinking goes something like this:
"I'm now creating a class which might get used from a lot of other classes, flexibility is a must. Let me use abstract factory to abstract out the creation. Oh and strategy just in case I need to change the behaviour based on composition. But what about default behaviour? Let me just create a singleton for that."
And this is all without writing a single line of code. Now you can see where this is heading to.
Design patters are not bad per se but "if all I have is a hammer, everything looks like a nail" and "flexibility of my classes is of prime importance" leads to nightmares as already mentioned above. This is the reason I strictly ask junior programmers to not put in a patter unless they can show me the problems that the current code is causing and put a solid case of listing down the benefits our project can get by using a particular pattern. Works well in most of the cases...
I agree heartily with most of the comments so far. They tend to reinforce my impression that knowledge of patterns can be useful if accompanied by a good introduction and to orientation their use in software development process.
Regarding their use with requirements, some research has been done trying to bridge and translate requirements to some types of patterns. We are not currently looking at that problem now. We accept requirements, good or bad as in any project, and make efforts to make them stable, understandable, and acceptable to stakeholders as we can before we get into general design, and repeat this as many times as necessary. I deal with this subject in my classes every semester.
Once requirements have been agreed upon (at least temporarily), general architectural design can begin or proceed. At this point, a check can be made against known architectural patterns to see if there is a good fit with one or more patterns. (See e.g. Pattern-Oriented Software Architecture - Buschmann, Henney)... Sketch some code, e.g. an abstraction hierarchy, to reflect the selected architecture. Most books will have some skeletal code along with each pattern. See if it makes sense for you project. If not, so be it, you can do it on your own as you see fit.
The story repeats itself for selecting design patterns in similar manner for the roles (participants) in the architectural design. There are said to be more than 2000 design patterns in Grady Booch's repository, which we could never reach. Don't let that number scare you. There are works on pattern recommenders to aid select best ones for you (in research stage now). You can modify an existing one (e.g. from Gang of Four or others) if you think it might be useful to you or others in the future. Be sure to document it with the standard info for patterns. Emphasize differences from apparently similar ones.
I've probably exceeded normal reply quota. So I'll end here. One parting request, if there are any members who want to make patterns more useful in software industry (as they are in many other industries-e.g. construction, genetics, data mining), as practitioners and academicians, we would like to hear from you.
Excellent piece of knowledge, I had come back to read concerning your web site from my friend shiva, bangalore. I have readed atleast eight posts of your website and let me tell you, your website provides the most fascinating information. This is the knowledge that I had been craving for, I am already your rss reader currently and that I would frequently be careful for the new posts. Thanks plenty another time, Regards, <snipped spam>
We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.