|
Design patterns can be seen as such a set of spells—apt to be promoted as a way to ensure that software systems will work and that someone who understands the concepts can expect to be able to maintain the systems effectively. "Any sufficiently advanced technology is indistinguishable from magic."
|
|
|
|
|
A slavish adherence to the fool's gold that can be design patterns may lead you down the path of over-engineered solutions that are hard to maintain and build upon. Whilst patterns, in a generalized way, are good for thinking about how to address a known or recurring problem they are not a one-size-fits-all solution to whatever you are trying to model or solve. They have a place and a part to play, just don't let them become the raison d'être of your solution. I say that because I've seen it. Experience trumps exuberance.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Your ideas are intriguing to me and I wish to subscribe to your newsletter.
My feelings exactly (and sadly/happily I lost out on a job because I expressed those feelings in a recent interview)
--------------
TTFN - Kent
|
|
|
|
|
Kent Sharkey wrote: I lost out on a job because I expressed those feelings in a recent interview
You need to learn about the bite-your-tongue pattern. 
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
mark merrens wrote: You need to learn about the bite-your-tongue pattern.
Yeah, that's a tough one. Is it in Fowler?
--------------
TTFN - Kent
|
|
|
|
|
You wouldn't have liked that job.
One place I interviewed at some years back asked me to take a look at some code and suggest a fix. Everything was a Singleton! I'm glad I didn't get the job. I took a job doing VB.net instead.
|
|
|
|
|
If one does not refrain from using common sense as regards programming in general and specifically design patterns, then said one shall be thrown under the bus, burned at the stake, drawn and quartered, eviscerated, and hung by their own entrails until dead or until such time as said one learns to keep their mouth shut and accept all ideas from their betters (i.e. the political elite) as the most awesome ideas to ever see the light of day.
True story, personal experience; but I'm not bitter. 
Comments from work:- "Why can't you just do it like everybody else?"
- "Well, we haven't had any complaints yet."
- "I just want to get it into production."
- "It only matters if it’s important to someone who matters."
|
|
|
|
|
The article at InfoQ in the first post contains:
Indeed, this enthusiasm for pattern mining has tended to obscure some key questions that remain largely unanswered, such as
the design process question: Do patterns form an effective way of exchanging design knowledge? and
the design product question: Do patterns help us to create designs that are easier to understand and maintain?
Neither question seems to have received much consideration from design pattern enthusiasts.
A lot of the newer patterns I've read about since "Design Patterns" was written were extracted from a specific solution instead of being gleaned from a plethora of existing designs, as was done for the patterns in the book. These "new" patterns are generally not useful to me.
Some other "new" patterns I've read about are minor variations, or specializations, of patterns listed in the book. In most cases, the author of these new patterns seem unaware of the original pattern. (This seems most common for the Strategy pattern and the Observer pattern. If you put an instance in a subclass in a list, a dictionary, or make it on the fly, if the instance represents a "state", then the "Strategy" pattern is being used, and renaming for some special implementation probably will create more confusion than it will help designers).
The patterns in "Design Patterns" are extremely common. A great many designs created before the book used at least one pattern in the book. For one example from the book, most (all?) modern word processing programs that allow changing fonts and font-attributes in the world uses the Flyweight pattern. That they all use the same pattern as a specific solution is a testament to that using the pattern is good design - for that specific problem. Of course, it's not good design to use the Flyweight pattern anywhere it could be used.
The book "Design Patterns" not only names and describes patterns, but it also lists the advantages and disadvantages of a pattern. This is also missing from many new patterns I've encountered.
I think the author of that article is onto something when pointing out that those questions often aren't mentioned in the context of newer patterns, but I think the more fundamental reason that new patterns would fail to satisfy the proper answer to these questions is because the concept of "creating" patterns is likely to be flawed to begin with. Patterns should generally be "discovered" after gaining familiarity with many software solutions.
modified 8-Jan-14 22:13pm.
|
|
|
|
|
Alan Kay, as usual, had something relevant to say here:
Quote: The most disastrous thing about programming — to pick one of the 10 most disastrous things about programming — there's a very popular movement based on pattern languages. When Christopher Alexander first did that in architecture, he was looking at 2,000 years of ways that humans have made themselves comfortable. So there was actually something to it, because he was dealing with a genome that hasn't changed that much. I think he got a few hundred valuable patterns out of it. But the bug in trying to do that in computing is the assumption that we know anything at all about programming. So extracting patterns from today's programming practices ennobles them in a way they don't deserve. It actually gives them more cachet.
The GoF book, for example includes the Singleton pattern, which should really be an Anti-Patterns book, as it introduces static dependencies and complicates testing (a global variable by any other name).
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
I'm glad I'm not alone in feeling that way.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Yeah, I'm currently working on a system where there's about 47 different singletons. All are then gathered in a single "Service" singleton to give "easy access" to the available services. Of course, that then exposes code, types and interfaces where they're not needed. Which causes unnecessary dependencies. It's a tangled mess!
Talk about high coupling and fragile code! Yuck!
If your actions inspire others to dream more, learn more, do more and become more, you are a leader.-John Q. Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering.-Wernher von Braun
Only two things are infinite, the universe and human stupidity, and I'm not sure about the former.-Albert Einstein
|
|
|
|
|
I feel your pain!
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
Rob Grainger quoting Alan Kay:
Rob Grainger wrote: But the bug in trying to do that in computing is the assumption that we know anything at all about programming.
That might be a valid point in the future, but the patterns in "Design Patterns" are relevant to right now.
Most developers typically use at least one of the patterns, such as Factory, Abstract Factory; Builder; Command; Memento; Observer; Visitor; Strategy; Flyweight; and other patterns that I've forgotten, even if they don't recognize the pattern. So, giving these patterns a name is important because it allows communicating, and thinking about, designs in ways that were not possible before. It's good to have words for patterns that developers often use today.
Rob Grainger wrote: The GoF book, for example includes the Singleton pattern, which should really be an Anti-Patterns book, as it introduces static dependencies and complicates testing (a global variable by any other name).
I have yet to see a better solution to enforce allowing only one instance of a class type. That is the point of a Singleton. The pattern has disadvantages, and some are listed in the book, along with the advantages. I've seen it used successfully in a very large code base and there were no problems due to it being used.
modified 9-Jan-14 21:30pm.
|
|
|
|
|
i roll my eyes twice-round whenever someone trots out a design pattern.
it's learning in reverse. a pattern should be something you recognize when you see it, not something you try to force the solution into while you're still trying to figure it out.
|
|
|
|
|
Microsoft is getting ready once again to give developers a chance to go deep into Windows with the 2014 edition of its BUILD conference. This year's event was held in late June in San Francisco and it seems Microsoft liked the location so much, the 2014 BUILD conference will be held in the "City by the Bay" yet again. Just in case you want to book any travel (SF is wonderful in April)
|
|
|
|
|
The anti-virus software will stop getting updates, and you won't be able to install it. What a strange coincidence
|
|
|
|
|
WTF FTW!
For The Win (FTW)
|
|
|
|
|
Google on Wednesday was slapped with a fine by French regulators for violating privacy laws in the country. And it will take them... oh, sorry, they've already earned enough to pay it.
|
|
|
|
|
If you’re a Java developer, chances are you did pretty well for yourself in 2013. "The classics are something that everyone wants to have read but no one wants to read."
|
|
|
|
|
All that says is that Stack Overflow's Careers 2.0 site attracts employers advertising Java jobs, maybe because there are plenty of Java developers registered, etc.
It's like rating a language's popularity by questions on sites like this - it may just mean the language is disproportionately hard.
"If you don't fail at least 90 percent of the time, you're not aiming high enough."
Alan Kay.
|
|
|
|
|
From chips to wearables to celebrities, all manner of technology popped up on stage and the show floor. My favorite is the smart onesie. Coffee time=baby monitoring time?
|
|
|
|
|
According to a study by New York-based risk management specialist Continuity Software, measurement and analysis is the key to achieving IT excellence. "Specific, Measurable, Attainable, Relevant and Time-bound."
|
|
|
|
|
Yeah, like that ever happens.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
Those who seek perfection will only find imperfection
nils illegitimus carborundum
me, me, me
me, in pictures
|
|
|
|
|
Microsoft co-founder Bill Gates is more involved with the company's search for a new executive than originally thought, a new report claims, citing a source who says Gates plans to "much more involved in the company going forward." So he's done working with polio vaccines and toilets?
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
