Design Patterns
-
It is, but they are very close to eachother, arguably M-V-VM is a specialisation of MVC: Common To Both: Model: Your everyday garden variety OM View: The GUI that displays to the user Depends Who You Ask: Controller: Inherently part of MVC, but may or may not be part of MVVM depending who you ask. The layer that orchestrates the work, deciding which view is displayed gets the OM to do stuff in repsone to GUI/other events etc. The MVVM Difference View Model: An intermediary layer between the view and the model. Typically the VM is bound to the view, reacting to to GUI events or providing UI-specific values based on information in the state. I can see why this is confusing though, there are a lot of articles on the Tinterweb with varying degrees of clarity and accuracy. To see a MVVM work well you should try it in WPF or Silverlight. It is quite possible to do without the controller. The chances are, if you are writing and MVC3 application you will have ViewModels where there is stuff you don't want in the OM but need to display in the view. To muddy the issue, I have seen an MVVM system with a controller described as MVCVM where people don't agree that this is really just MVVM
Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^] -
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
I work with another developer who has invented his own code-formatting pattern that I have decided to name the "Horribly Ugly Really Lame" pattern (HURL for short), because that's what it makes me want to do every time I look at his C/C++ source code. X|
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
-
I'm surprised we don't hear this viewpoint more often, it is getting ridiculous and I suspect a backlash may start soon. The original GoF idea was good: find common solutions to common problems, describe them and give them a name so we all have a shorthand to know what we are talking about. Fine in theory, until it becomes the thing-de-jour and every Tom, Dick and Henrietta decides to create their own "patterns" and bang on about it. Worse, people throw the name of a pattern around in a way to suggest that because there is a pattern it is applicable and no further discussion is available. Hey I discovered a new pattern, the Unary Increment Pattern:
i++;Sort of a cross between Lawrence of Arabia and Dilbert.[^]
-Or-
A Dead ringer for Kate Winslett[^]Well said - another problem that I tend to see a lot of, is developers that overcomplicates stuff because they feel they have to use a pattern, turning even the simplest things into major development efforts.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
-
Huh... So... In English, DI/IOC = "Choose interface implementations in config files" Yeah, I've done that before, without the buzzwords :)
Proud to have finally moved to the A-Ark. Which one are you in?
Author of the Guardians Saga (Sci-Fi/Fantasy novels)Damn right. Except that in interviews where they want someone who is an "IOC Expert" they want you to fart on about it until you're blue in the face. :zzz:
I too dabbled in pacifism once.
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
You are right, but I must add that having a good practice, already widely used, codified in a common but regular language, makes it much easier to communicate on aspects, and use of, that practice.
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
If memory serves, it was the late Grace Hopper who said:
"We never do anything new in this field; we just rename the old stuff."
It does make for a lot of new books every two or three years, though.
(This message is programming you in ways you cannot detect. Be afraid.)
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
I never understood the basis for the names of some of the patterns. Their names should absolutely reflect the function of the pattern so normal coders will have a chance at hitting references to it in a web search or in discussion. Because otherwise, we're just hiding the patterns from the very folks that will benefit the most from them!
-
Now that I've managed to get some idea of what it is (and now have a name for the exact thing I hate most about the code I have to work with), I can think of good applications for DI (but really, isn't that covered by interfaces/abstract classes?), but IoC just makes things difficult to maintain :doh: Where is this class? Oh...I don't get to know because it's hidden by the IoC container...awesome...
+1, agreed. I find IoC to be taking the whole abstraction thing a little too far. I guess the idea is to take away dependencies for testing because you can mock everything, but I don't really see the point - you have to test everything anyway...
-
mark merrens wrote:
how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful?
I'm still trying to figure out IoC and dependency injection...can't seem to find any examples that a) make sense to someone with a short attention span b) provide a realistic example of why I should care but there seems to be a big fuss about them, so I must be missing something...
Isn't DI/IoC just another way of loose coupling?
-
Well said - another problem that I tend to see a lot of, is developers that overcomplicates stuff because they feel they have to use a pattern, turning even the simplest things into major development efforts.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
I think that's the biggest problem with all this pattern driven design. People just need to think about the best way to solve a problem and do it instead of trying to fit the problem into one of the pre-existing patterns.
-
Damn right. Except that in interviews where they want someone who is an "IOC Expert" they want you to fart on about it until you're blue in the face. :zzz:
I too dabbled in pacifism once.
-
I think that's the biggest problem with all this pattern driven design. People just need to think about the best way to solve a problem and do it instead of trying to fit the problem into one of the pre-existing patterns.
I think I should add that when I take on larger projects, I sometimes reread books like Pattern-Oriented Software Architecture: A Pattern Language for Distributed Computing[^]. It kind of helps me to put "ze little grey cells" into the right mood.
Espen Harlinn Principal Architect, Software - Goodtech Projects & Services AS My LinkedIn Profile
-
Unless it's a meaningless name... On many occasions, usually during job interviews, I have been asked about some "named" technology and my answer has usually had to be "I've heard of it; tell me what it is and I'll tell you if I've used it". Often I find I have been using some pattern for a long time (in a nameless kind of way) and only when someone puts a name on it do I suddenly find myself feeling ignorant! The patterns I know are the "thingy" and the "other thingy" and the "singleton" (I've worked out roughly what that one was)! ;P ...by the way - I usually got the job!
- Life in the fast lane is only fun if you live in a country with no speed limits. - Of all the things I have lost, it is my mind that I miss the most. - I vaguely remember having a good memory...
I invented a lovely pattern for organising data into linear lists with mappings between them and used it successfully in several projects. Then someone called Ted Codd came along and wowed the world with relational databases and 3rd Normal Form. Not materially different in any way from what I was doing. Another scheme that I invented was a way of referencing devices anywhere in the world by a hierarchical numbering systems (based on octets). I could not resolve the problem of spoofing (how to authenticate that a device was who it said it was; and not some other device masquerading as the intended device), so I gave up. Sometime later, someone inflicted IPv4 on the world. That was non-hierarchical (you have to put the full address even for local devices), based on octets, and has just ignored the spoofing problem. Inferior to what I had designed.
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
I thought that most of the "nonsense verbiage" was there not to describe the pattern, but to help you decide whether it applied to the case you were struggling with. Doing that in general leads (inevitably, one might surmise) into abstraction. Patterns became popular because they were heavily marketed by the Object-Oriented tool vendors, particularly Rational. Now that the money is in pattern matching against simple data types, the idea at the core of OO design - building models of systems - is less compelling than it was once, and so the value of classifying and regularizing models may seem less obvious. For the coder, the idea is that the name of the pattern should give you a direct sense of what you're going to see when you look at the implementation. Great for design sessions and code reviews - for those that participate in them.
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
A good design pattern document is like a spec sheet. It may contain information you don't need. It's still nice to have it. In order to qualify in a meaningful way as a design pattern, the pattern must be abstract enough to not be tied to a particular language or situation, and must recur often enough to be worth abstracting. Many coding idioms are proposed as design patterns, but fail one of these tests. It would be cool to have your name on a design pattern. I think that's too motivating for some people. Another problem with design patterns is that you must remember them, or have means to look them up. I didn't know what dependency injection was for the longest time. When I finally decided to look it up, it was, "Oh yeah, that. I do that." On the other hand, my first introduction to model-view-controller was an eye-opener. The design pattern community is far from having a good way to look up design patterns by describing a problem you need solved, for which the pattern is the solution. Partly that's because when you have a problem, you probably can't articulate it very well. Reading books of design patterns is a poor way to acquire the needed knowledge. Certain recent graduates are very proud that they know design patterns, and may know the names of dozens. To these people, anyone who doesn't know the FooBaz pattern is a dinosaur. It's hard to talk to these people if you know the FooBaz pattern by a different name, or if you know how to apply it, but didn't know it was a capital-D Design Pattern and was called FooBaz. In fact, it's hard to talk about design patterns in general unless you have a shared understanding of them. This is another weakness that the Design Pattern movement has yet to address. I haven't checked, but I betcha there are whole web sites devoted to cataloging design patterns. Anyone want to recommend a couple of good ones?
Only the signature has been changed, to protect the innocent
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
It's all about human herd instinct. Make it fashionable, and the herd will flock to it. I've sifted through hundreds of thousands of lines of code lately (maybe last three months or so), and have yet to see a sound strategy implementation. Which is why it's (IMO) still important that patterns get advertised - there seems to be a huge spread in how well prepared programmers are, a lot larger than in the professional knowledge in other domains.
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
Astonishing ! I've recently attended a couple of interviews where I was asked about design patterns, so yesterday, I thought maybe I hould read up on them a little. I came to just about the same conclusions. Surely, it's more or less just common sense to someone who's done a bit of programming.
-
Don't ask me there is only one pattern I full understand. Drink Beer, Drink Spirits, Drink More Beer, Drink More Spririts........fall over.....go home. :)
Dave Find Me On: Web|Facebook|Twitter|LinkedIn
Folding Stats: Team CodeProject
-
Sometimes, when I read pattern definitions, I can imagine the author/s sitting there going how can we make this reasonably simple idea that's been around for years and years in various forms sound really, really smart and, at the same time, give it a really funky name like 'The Strategy Pattern' or 'The Chain of Responsibility Pattern'? Or how can we make this pile of nonsensical verbiage sound as if it actually does something meaningful? Don't get me wrong; I rather like patterns or, at least, some of them. I just find it amusing that some basic ideas suddenly get popular because they get a groovy makeover.
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair. nils illegitimus carborundum me, me, me
Yeah. At the time that GoF book came out, I was totally confused by all those crazy pattern buzzwords that were flying about. Until I had some external have a look at my software design to get some feedback and he told me that "yeah, that's the observer pattern alright, and thats the watchamaycallit pattern I recognise over there... looks fine to me." That was the point when I realized I didn't miss anything at all - except the funky new names. Now I do wonder why it took four people just to invent new names for stuff that has been around for decades! :confused: