Design patterns have (mostly) flopped
-
http://www.supercoders.com.au/blog/designpatternshavemostlyflopped.shtml
This article, as far as I can tell, is a thinly-veiled attempt to encourage developers to learn design patterns so it's easier to mark that check-box during recruitment.
Bonus, there's a minor CodeSOD WTF in the page artwork (IMO).
-
@frits said:
Bonus, there's a minor CodeSOD WTF in the page artwork (IMO).
Clearly the artist and developer don't communicate. 40 line posts should be enforced.
-
Design patterns have flopped? Perhaps if you expected them to be the only thing you'd ever have to learn about programming. Need a C++ parser? Well, just add one singleton, two factories, and a few bridges, and you'll be done. Need a transaction processor? Two singletons, five factories, and a few wrappers around a state.
And what's with the color of the line numbers?
-
I just wonder how Fri 14 May 2010 and Fri 05 May 2010 can both be legal dates? Isn't there some design pattern for automatically dating blog posts so that the author doesn't have to embarrass himself with trying to find a legal combination of date and weekday?
-
Design patterns have mostly flopped because the vast majority of programmers have little or no knowledge of this important field of computer science.
TDWFT exists (mostly) because the vast majority of programmers have no knowledge any field in computer science.
-
@{SuperCoders} said:
The idea behind design patterns is that they are tried and true solutions to recurring problems in software development. When a programmer encounters one of these recurring problems they implement the appropriate design pattern to solve it.
If memory serves me, the famous GoF book set out to name and describe commonly used patterns so we'd have a consistent vocabulary for discussing them. I don't remember them claiming to have the answers to all design problems, though everyone citing these patterns seems to think they're gospel.
Also, computer scientists don't worry themselves over practical things like writing software.
-
@frits said:
This article, as far as I can tell, is a thinly-veiled attempt to encourage developers to learn design patterns so it's easier to mark that check-box during recruitment.
Worse than that, I think it's thinly veiled search-engine spam to attract people to the recruiter's website when they search for terms like 'design patterns'.The idea behind design patterns is that they are tried and true solutions to recurring problems in software development. When a programmer encounters one of these recurring problems they implement the appropriate design pattern to solve it. Design patterns have been worked out by some of the smartest computer scientists and tested over time so they are solid and known to be good solutions. With design patterns, the programmer does not need to come up with their own solutions to a whole range of programming challenges; instead they use pre-rolled design patterns. Design patterns save development time and lead to more flexible, reliable and robust software. Design patterns is about reusing the conceptual ideas, solution design and thinking of other people. It's a great idea and make a whole lot of sense.
-
@eBusiness said:
I just wonder how Fri 14 May 2010 and Fri 05 May 2010 can both be legal dates? Isn't there some design pattern for automatically dating blog posts so that the author doesn't have to embarrass himself with trying to find a legal combination of date and weekday?
And some of you still claim there was no Y2K bug!
-
@da Doctah said:
And some of you
[who?]
-
@da Doctah said:
And some of you still claim there was no Y2K bug!
I'm mailing this from the elevator I got stuck in early in the morning of 1/1/2000, so that wasn't me!
-
Name every design pattern that you can recall
Oh, cool, it's like taking a university exam all over again. If they had bothered to teach us design patterns that is. How many points is each pattern worth? How many do I need to pass the class?Design patterns have been worked out by some of the smartest computer scientists
While I learned most of them from studying other people's work or from the GoF, there are a few I implemented myself before I knew they had a name. I guess that makes me one of the smartest computer scientists.the programmer does not need to come up with their own solutions to a whole range of programming challenges; instead they use pre-rolled design patterns.
Only a matter of time now before the boss comes around and goes "Hey John, you're using design patterns right? Make sure to put some in the XML I told you to use."
-
@davedavenotdavemaybedave said:
Worse than that, I think it's thinly veiled search-engine spam to attract people to the recruiter's website when they search for terms like 'design patterns'.
They're doing it wrong.
The idea behind design patterns is that they are tried and true solutions to recurring problems in software development. When a programmer, like Miley Cyrus if she were a programmer, encounters one of these recurring problems, like the coding equivalent of Justin Bieber taking her publicity away, they implement the appropriate design pattern to solve it. Design patterns have been worked out by some of the smartest computer scientists and tested over time so they are solid and known to be good solutions. With Paris Hilton--I mean design patterns, the programmer does not need to come up with their own solutions to a whole range of programming challenges; instead they use pre-rolled design patterns, just like Lindsay Lohan might use pre-rolled dubies. Design patterns save development time and lead to more flexible, reliable and robust software. Design patterns is about reusing the conceptual ideas, solution design and thinking of other people like Megan Fox, who just might use your software. It's a great idea and make a whole lot of sense. Snooki and The Situation don't make a lot of sense.
There, that would probably yield more visits to their landing page.
-
@heffkat said:
@frits said:
Bonus, there's a minor CodeSOD WTF in the page artwork (IMO).
Clearly the artist and developer don't communicate. 40 line posts should be enforced.
I actually talking about upload filtering by file extension, but that's pretty good too.
-
@davedavenotdavemaybedave said:
@frits said:
This article, as far as I can tell, is a thinly-veiled attempt to encourage developers to learn design patterns so it's easier to mark that check-box during recruitment.
Worse than that, I think it's thinly veiled search-engine spam to attract people to the recruiter's website when they search for terms like 'design patterns'.The idea behind design patterns is that they are tried and true solutions to recurring problems in software development. When a programmer encounters one of these recurring problems they implement the appropriate design pattern to solve it. Design patterns have been worked out by some of the smartest computer scientists and tested over time so they are solid and known to be good solutions. With design patterns, the programmer does not need to come up with their own solutions to a whole range of programming challenges; instead they use pre-rolled design patterns. Design patterns save development time and lead to more flexible, reliable and robust software. Design patterns is about reusing the conceptual ideas, solution design and thinking of other people. It's a great idea and make a whole lot of sense.
You may be on to something there. I saw this article because of the CodeProject.com daily news. Maybe they have an automated news crawler.
-
@frits said:
I actually talking about upload filtering by file extension, but that's pretty good too.
Yup, that one struck me too. It's pretty common though.
-
AGH!! I knew I should have picked up those books on design patterns, but I spend too much time actually programming to read them. I am so out of date and out of touch with the current stuff.
Isn't it sort of disingenuous to call design patterns the "lingua franca" of programming and then in the same paragraph disdain that the majority of programmers don't understand enough about design patterns?
-
Am I the only one who hates the useless, fixed-position footer?
-
@Schlagwerk said:
I have seen that design pattern on a few different pages, it takes up a lot of space, and in this case it looks particularly dumb because the header doesn't follow the same principle.Am I the only one who hates the useless, fixed-position footer?
-
@Medezark said:
AGH!! I knew I should have picked up those books on design patterns, but I spend too much time actually programming to read them. I am so out of date and out of touch with the current stuff.
Isn't it sort of disingenuous to call design patterns the "lingua franca" of programming and then in the same paragraph disdain that the majority of programmers don't understand enough about design patterns?Yah I never learned anything about design patterns in school. Or after school. And I don't particularly care... any place so rigid that they follow the Design Patterns book like a Bible, I probably don't want to work for anyway.
Actually all this talk of design patterns reminds me of the No Silver Bullet essay. But I'm guessing people who worship design patterns don't read Fred Brooks.
-
@blakeyrat said:
Yah I never learned anything about design patterns in school. Or after school. And I don't particularly care... any place so rigid that they follow the Design Patterns book like a Bible, I probably don't want to work for anyway.
Read http://www.amazon.com/First-Design-Patterns-Elisabeth-Freeman/dp/0596007124. It's not about following a certain religion, but about figuring out how to do OO well.
-
The author of the article is also missing one really important fact. The libraries and OS tools we use to write software are usually built around design patterns so we don't have to implement them ourselves. Things like .Net, Java, Cocoa, etc. already have a very rich set of classes that implement MVC, delegates, singletons, etc. It's like saying that a delivery person is deficient in their job because they don't know how to take apart a transmission and rebuild it. I don't have time to write an entire OS and supporting libraries that implement every design pattern. So I use one which already exists, and I implement the stuff specific to my problem that might less easily fit into an existing pattern.
-
This IS a stupid article... he's basically saying "if more people knew design patterns, more people would use them" - well... DUH! You could say this about any concept in computer programming or any other field. He is right - it is annoying when someone invents a solution for a known problem, even more annoying when their solution is wrong...
And yeah, it's probably a Google bomb
-
@dcardani said:
The author of the article is also missing one really important fact. The libraries and OS tools we use to write software are usually built around design patterns so we don't have to implement them ourselves. Things like .Net, Java, Cocoa, etc. already have a very rich set of classes that implement MVC, delegates, singletons, etc. It's like saying that a delivery person is deficient in their job because they don't know how to take apart a transmission and rebuild it. I don't have time to write an entire OS and supporting libraries that implement every design pattern. So I use one which already exists, and I implement the stuff specific to my problem that might less easily fit into an existing pattern.
There are plenty of places where you need to implement your own very specialized logic into a project that require extending the libraries or framework where knowledge of design patterns would aid you. If anything, there are different flavors of patterns which each have their strong points and weak points depending on what you are trying to do, and knowing those pros and cons will help you find the right framework. Your analogy makes no sense anyway, since that's more analogous to a user of your software not needing any skills in design patterns. We are software engineers, utilizing design patterns is one of many skills that I'd say is essential to at least making decisions in a senior position if not a mid-level position.
You don't have to memorize every known design pattern, either. Just know that they are there and when you reach a challenging task that requires some thinking and planning about the best way to implement it robustly, know where to look. Patterns work on a large scale, like a framework, but they also work on small scales like implementing asynchronous initialization within a class.
-
@RHuckster said:
@dcardani said:
The author of the article is also missing one really important fact. The libraries and OS tools we use to write software are usually built around design patterns so we don't have to implement them ourselves. Things like .Net, Java, Cocoa, etc. already have a very rich set of classes that implement MVC, delegates, singletons, etc. It's like saying that a delivery person is deficient in their job because they don't know how to take apart a transmission and rebuild it. I don't have time to write an entire OS and supporting libraries that implement every design pattern. So I use one which already exists, and I implement the stuff specific to my problem that might less easily fit into an existing pattern.
There are plenty of places where you need to implement your own very specialized logic into a project that require extending the libraries or framework where knowledge of design patterns would aid you. If anything, there are different flavors of patterns which each have their strong points and weak points depending on what you are trying to do, and knowing those pros and cons will help you find the right framework. Your analogy makes no sense anyway, since that's more analogous to a user of your software not needing any skills in design patterns. We are software engineers, utilizing design patterns is one of many skills that I'd say is essential to at least making decisions in a senior position if not a mid-level position.
You don't have to memorize every known design pattern, either. Just know that they are there and when you reach a challenging task that requires some thinking and planning about the best way to implement it robustly, know where to look. Patterns work on a large scale, like a framework, but they also work on small scales like implementing asynchronous initialization within a class.
Based solely off of your reply to SpectateSwamp, you seem to be intuitive and level headed. I will look into these "patterns" of which you speak.
-
@dcardani said:
The author of the article is also missing one really important fact. The libraries and OS tools we use to write software are usually built around design patterns so we don't have to implement them ourselves. Things like .Net, Java, Cocoa, etc. already have a very rich set of classes that implement MVC, delegates, singletons, etc. It's like saying that a delivery person is deficient in their job because they don't know how to take apart a transmission and rebuild it. I don't have time to write an entire OS and supporting libraries that implement every design pattern. So I use one which already exists, and I implement the stuff specific to my problem that might less easily fit into an existing pattern.
I agree. But the libraries are not withouth fail themselves: For example is the single-instance Tuple referred to as a "Singleton". Which might just give enough people the wrong idea. Despite the fact that a perfectly fine example exists.
On the other hand, when do you really need a Singleton anyway? And by that I mean: Where does it solve a problem that a static class wouldn't solve? The funny thing in C# is that you can always get around the "single" restriction by subclassing.@jasmine2501 said:
This IS a stupid article... he's basically saying "if more people knew design patterns, more people would use them" - well... DUH! You could say this about any concept in computer programming or any other field. He is right - it is annoying when someone invents a solution for a known problem, even more annoying when their solution is wrong...
And yeah, it's probably a Google bomb
The irony is that we're making it look like a legit article by discussing it here.
-
@frits said:
@heffkat said:
@frits said:
Bonus, there's a minor CodeSOD WTF in the page artwork (IMO).
Clearly the artist and developer don't communicate. 40 line posts should be enforced.
I actually talking about upload filtering by file extension, but that's pretty good too.
I thought it was the infinite loop you get thrown into if your file extension matches.
-
@Shortjob said:
The irony is that we're making it look like a legit article by discussing it here.
The reason I posted it was because it was included in a legitimate industry newsletter, even though it's actually hogwash. Hence making it a WTF of the non-code kind.
-
@shortjob said:
The irony is that we're making it look like a legit article by discussing it here.
Thing is, this is kind of like slashdot articles; the article is really just a good way to start conversation about a topic. Although, I did RTFA.
[I'm going to regret this post later... I took some cold medicine and it kicked in right as I was writing what follows. Bear this in mind before flaming me]
Anyways, I have mixed feelings about design patterns. On the one hand, I agree with the theory and spirit behind them. OTOH, there seems to be a high correlation between "design pattern cheerleaders" and "cargo cult programmers", IMHO (I feel the same about agile, XP, etc in general though). I've found that I implement known patterns all the time and I think the reasoning comes down to two primary reasons:
- There are many design patterns.
- The patterns are common sense and usually the simplest, most straight-forward ways to accomplish the task. They don't need a name.
The other problem I have with the mindset is that not every problem fits neatly into a single category and trade offs to a design must be made to accommodate the common case. If you're sitting there measuring up patterns to your task, you're probably attacking from the wrong angle. You should be attacking from the point of view of what you need, not what you have.
-
@Gazzonyx said:
The other problem I have with the mindset is that not every problem fits neatly into a single category and trade offs to a design must be made to accommodate the common case. If you're sitting there measuring up patterns to your task, you're probably attacking from the wrong angle. You should be attacking from the point of view of what you need, not what you have.
The best part is when people pick design patterns that aren't even slightly appropriate for what they're doing. If it's not a design pattern, it's not allowed!
-
@Gazzonyx said:
The patterns are common sense and usually the simplest, most straight-forward ways to accomplish the task. They don't need a name.
I find them useful when reading foreign code bases when people give hints to the DP used in a class based on the name (eg: XFactory) since it usually explains why the code does something in that specific way. Being able to recognize them makes seeing anti-patterns easier, and can help indicate when they're being misused. Although yes they're common sense in many cases what's not common is the collective knowledge of when and where each is best applied or if any should be applied at all.
-
@Gazzonyx said:
The patterns are common sense and usually the simplest, most straight-forward ways to accomplish the task. They don't need a name.
Bookmarking a page is a usage-pattern that is a simple and straightforward and common way of accomplishing its task . It is called "bookmarking a page", so that people can refer to it.
So yeah, if it is real and if it is handy, then it needs its description compressed into an ID, which is the name.
Next up: a primer on semantics, symbol grounding and theory of mind!
-
Does anyone have any proof that there is anyone who actually DOES use design patterns like lego blocks, because I think this is just one of them imaginary strawmen concepts that don't actually exist but we like to rag against the concept anyway.
-
Computer science is really a branch of mathematics, somewhat more applied than others, but still mostly about abstract concepts. Most people have a tough enough time with arithmetic. Why would we expect them to understand the mapping between design patterns and code? And especially the benefits of the patterns. An intelligent programmer who pays attention, learns from his mistakes and from other people's code, has probably come up with or picked up a lot of them to begin with.
Learning them from a book can shorten the process, obviously, and learning the names is useful for communicating with others who understand and know them, too. The simple fact of knowing some patterns isn't much different than having taken, say, a data structures class in college. Neither is a prerequisite for knowing the material, nor are they guarantees.
-
Just letting you know that we're now on the google front page for "Design Pattern Miley Cyrus" ^_^
-
@Gazzonyx said:
@shortjob said:
The irony is that we're making it look like a legit article by discussing it here.
Thing is, this is kind of like slashdot articles; the article is really just a good way to start conversation about a topic. Although, I did RTFA.
[I'm going to regret this post later... I took some cold medicine and it kicked in right as I was writing what follows. Bear this in mind before flaming me]
Anyways, I have mixed feelings about design patterns. On the one hand, I agree with the theory and spirit behind them. OTOH, there seems to be a high correlation between "design pattern cheerleaders" and "cargo cult programmers", IMHO (I feel the same about agile, XP, etc in general though). I've found that I implement known patterns all the time and I think the reasoning comes down to two primary reasons:
- There are many design patterns.
- The patterns are common sense and usually the simplest, most straight-forward ways to accomplish the task. They don't need a name.
The other problem I have with the mindset is that not every problem fits neatly into a single category and trade offs to a design must be made to accommodate the common case. If you're sitting there measuring up patterns to your task, you're probably attacking from the wrong angle. You should be attacking from the point of view of what you need, not what you have.
OMG!!! I figured it out! "Design Patterns" are what we used to call Algoryihm's (I may have mis-spelled that). I DO know what Design Patterns are... and use them all the time. Why the heck are we calling the Design Patterns now?
-
@Shortjob said:
The funny thing in C# is that you can always get around the "single" restriction by subclassing.
Does C# not have an equivalent of Java's "final" modifier for classes?
-
@Someone You Know said:
@Shortjob said:
The funny thing in C# is that you can always get around the "single" restriction by subclassing.
Does C# not have an equivalent of Java's "final" modifier for classes?
The sealed keyword. However the usage of a singleton (at least how I use it) is more about global access than restriction. I usually use singletons to access things like objects that use a communications bus or loggers.
-
@Jedaz said:
@frits said:
@heffkat said:
@frits said:
Bonus, there's a minor CodeSOD WTF in the page artwork (IMO).
Clearly the artist and developer don't communicate. 40 line posts should be enforced.
I actually talking about upload filtering by file extension, but that's pretty good too.
I thought it was the infinite loop you get thrown into if your file extension matches.
Yeah, good catch. Although the loop would quite finite on any real computer.
-
@stratos said:
Does anyone have any proof that there is anyone who actually DOES use design patterns like lego blocks, because I think this is just one of them imaginary strawmen concepts that don't actually exist but we like to rag against the concept anyway.
Not sure how to prove it to you, but I've worked with someone who did exactly that. He read the GoF book and thought he found the Holy Grail.
-
@boomzilla said:
Learning them from a book can shorten the process
And it can block out all alternatives if such a concept is taught too early in a programmers life. The article pretty much states "you are too dumb to make a design on your own, so use a pattern made by a smart person, sucker". If you manage to teach that mentality to someone then they are bound to become cargo cult programmers of the most horrible kind, simply because they are afraid of thinking for themselves.Universities all over the world are spewing out object oriented zealots, 'cause that is the right way to code, and any book that says different is heresy. As great as the object oriented way may be, it is not healthy to know nothing else.
-
@eBusiness said:
I don't really disagree with that, but it may be that idiots who generate cargo cult patterns may create WTFs that are easier to figure out than home grown WTFs. Either way, they're going to keep this site in content.@boomzilla said:
Learning them from a book can shorten the process
And it can block out all alternatives if such a concept is taught too early in a programmers life. The article pretty much states "you are too dumb to make a design on your own, so use a pattern made by a smart person, sucker". If you manage to teach that mentality to someone then they are bound to become cargo cult programmers of the most horrible kind, simply because they are afraid of thinking for themselves.
-
@eBusiness said:
"you are too dumb to make a design on your own, so use a pattern made by a smart person, sucker"
And that doesn't apply to almost everything else to do with computers? IE when was the last time you wrote your own programming language? Design patterns are an abstraction just like a bunch of other stuff.
-
@OzPeter said:
@eBusiness said:
A programming language saves me time, there is a pretty obvious immediate benefit relative to hacking raw machine code, the same can't be said about design patterns, so that'll be the reason why I do my own "design patterns", but not my own programming language. As for being too dumb, if I couldn't code without design patterns, I doubt that I'd do much better with them. The biggest problem with design patterns is that it may be just as demanding to pick the right one as to come up with the right one, that doesn't mean reading about design patterns to get some inspiration is a bad idea, but I'd see it as no more than inspiration. I am a programmer because I don't need someone to hold my hand while coding. As for abstractions in general, they are dangerous if you only know the abstract layer, you can avoid a lot of pitfalls if you know what is going on, and when you know your abstractions they can be helpful."you are too dumb to make a design on your own, so use a pattern made by a smart person, sucker"
And that doesn't apply to almost everything else to do with computers? IE when was the last time you wrote your own programming language? Design patterns are an abstraction just like a bunch of other stuff.
-
@frits said:
@Jedaz said:
@frits said:
I actually talking about upload filtering by file extension, but that's pretty good too.
I thought it was the infinite loop you get thrown into if your file extension matches.
Yeah, good catch. Although the loop would quite finite on any real computer.
Are you talking about this?
Where's the loop?
-
@eBusiness said:
if I couldn't code without design patterns, I doubt that I'd do much better with them.
Agreed. Design Patterns tell you nothing about code quality. But if the code is already good, they provide you with information about how the code solves a given problem on an abstract level. That information can usually not be extracted from the code, but has to be looked up in a design document. That saves a good couple of minutes provided design documents are available.
@eBusiness said:
it may be demanding to pick the right one
That is true, but available books and classes do tell you how to pick the right one. Also, a pattern does not only consist of The Idea, The Code and The Transformation, but also about a thorough description as to what and why.
@eBusiness said:
as to come up with the right one
I don't think so. Granted, a good bunch of what's called a "pattern" these days (like MVVM) are little more than putting a name to the obvious solution. Other patterns like Flyweight or Composite are very sophisticated in both design and application.
(line empty for taking-a-breath-effect)
Everybody: To be honest, I am quite shocked about what transpired in this thread. Especially in regard to what design patterns are. I think we're on the same page regarding their usage: Implement X solve Y. But that's not the whole story. Every pattern just solves a specific class of problems and sadly, only few problems fall in such a class. The larger part of daily coding cannot be properly solved with patterns alone. I think the comparison to "Lego" is dangerously inaccurate. If we already had figured out how to create programs by stacking blocks, do you really think we'd be grinding our asses with programming?
And lastly, patterns are only useful during one stage: when planning the implementation. Most patterns require knowledge of the interfaces consumed by your app or provided internally. Likewise, some patterns do nothing but providing an interface (Iterator). Sometimes they are bound to a specific requirement, functional ("App is a service" => Singleton) or data ("App stores 5 mil highly redundant objects in mem" => Flyweight+Factory).I guess I could go on, but seriously </rant>
-
@Zecc said:
@frits said:
@Jedaz said:
@frits said:
I actually talking about upload filtering by file extension, but that's pretty good too.
I thought it was the infinite loop you get thrown into if your file extension matches.
Yeah, good catch. Although the loop would quite finite on any real computer.
Are you talking about this?
Where's the loop?
You need the whole picture:
-
-
@RHuckster said:
@frits said:
You need the whole picture:
The bottom is clearly not a continuation of the top.
I agree. Although the general layout suggests that the questionable line is indeed doing recursive call. Hence it's funny.
-
@RHuckster said:
@frits said:
You need the whole picture:
The bottom is clearly not a continuation of the top.
There isn't enough information to say definitely either way. Although the indentation suggests the bottom and top are matched and we just don't get to see all the code in between.
-
@frits said:
Wow, how did I miss that?You need the whole picture:
Still, the indentation doesn't really match.
PS: Okay, now I see why. The first time I visited I only payed attention to the layout after scrolling the header out of view.
PS2: Just visited their home page. To find their contact information (other than phone) in this wonderful site layout, you have to scroll past all the content.
Also, they haven't quite decided whether their section headers should be hyperlinkish blue or pink, and whether their links should been underlined or not. Great design.
