General "design patterns" usage questions
-
Gerry Schmitz wrote:
The odds of finding 2 people in the same room who CAN talk patterns is zero.
I would not state that during an interview :) At Cadac (previous employer) there's an architect that will take over the whiteboard and start explaining how the group of devs is going to build an application; it is assumed that everyone is at least up to date on the most used patterns. You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I studied the design patterns book written by the Gang of Four when it first hit the shelves in the mid 1990's and I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage. Do you use design patterns on a regular basis? In your view, has it fallen out of favor in the industry? If you use patterns regularly, do you have a source or sources of new patterns? TIA
Cheers, Mike Fidler "I intend to live forever - so far, so good." Steven Wright "I almost had a psychic girlfriend but she left me before we met." Also Steven Wright "I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
MikeTheFid wrote:
I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage.
Because the reality is that most of those patterns have little usage in the vast mess that is implementation. Not to mention of course that singleton, which is the only one used a lot, tends to be used incorrectly a lot as well. So that didn't help much.
MikeTheFid wrote:
Do you use design patterns on a regular basis?
In the generic sense, not the book, yes.
MikeTheFid wrote:
If you use patterns regularly, do you have a source or sources of new patterns?
My head. And not as rigorously as GoF defines it. I looked at several of the follow on books to the GoF and found that most were really struggling to find patterns. That along with how seldom I had seen (even then) most of the patterns in the GoF didn't really bode well. Further experience seems to have supported my determination that although the idea was valid it just wasn't prevalent enough to attempt to normalize it.
-
That was ONE person doing the "talking" ... "previously". And most "architects" rarely "implement"; they usually impede.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
Gerry Schmitz wrote:
That was ONE person doing the "talking" ... "previously".
The way you phrase that so carefully makes me feel uneasy, and I have no clue why :D
Gerry Schmitz wrote:
And most "architects" rarely "implement"; they usually impede.
That's the task of the manager, not the architect.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Gerry Schmitz wrote:
The odds of finding 2 people in the same room who CAN talk patterns is zero.
I would not state that during an interview :) At Cadac (previous employer) there's an architect that will take over the whiteboard and start explaining how the group of devs is going to build an application; it is assumed that everyone is at least up to date on the most used patterns. You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Yes, but does that really relate to what GoF defines? Following is the GoF definition for "Factory Method" (there is no "Factory"). "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiations to subclasses." Lets look at "Abstract Factory". The GoF definition. "Provide an interface for creating families of related or dependent objects without specifying their concrete classes." When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above? If it helps note that the GoF also says the following about a "Factory Method"
Use the Factory Method pattern when
- a class can't anticipate the class of objects it must create
- a class wants its subclasses to specify the objects it creates
- classes delegate responsibility to one of several helper subclasses and you want to localize the knowledge of which helper subclass is the delegate.
As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
-
Eddy Vluggen wrote:
You're a developer, after all, and the factory, singleton or decorator aren't a new idea.
Yes, but does that really relate to what GoF defines? Following is the GoF definition for "Factory Method" (there is no "Factory"). "Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiations to subclasses." Lets look at "Abstract Factory". The GoF definition. "Provide an interface for creating families of related or dependent objects without specifying their concrete classes." When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above? If it helps note that the GoF also says the following about a "Factory Method"
Use the Factory Method pattern when
- a class can't anticipate the class of objects it must create
- a class wants its subclasses to specify the objects it creates
- classes delegate responsibility to one of several helper subclasses and you want to localize the knowledge of which helper subclass is the delegate.
As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
jschell wrote:
Yes, but does that really relate to what GoF defines?
I'd seriously wouldn't know, I don't go there often :)
jschell wrote:
When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above?
No, just the generic idea, otherwise he would specify exactly what the requirements are. If he doesn't, then it is up to the developer to choose the most appropriate solution - which usually means going for the simplest thing possible (whilst still only returning an interface). ..but when in doubt, simply ask :thumbsup:
jschell wrote:
As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
Depends heavily on what is required; do you want a static factory, a singleton, or would you prefer an object? If it has to be combined with an object-manager pattern, then I'd think that the object is preferred. Do you want one object, or do you want multiple objects? In the first case, all objects created in the factory will be available over the manager globally. In the second case, only those objects are available that the specific factory created (in that thread). Point is, you don't want to explain how a "single point of creation in code" can save you from having to update a 1000 references in code where there's normally a "new"-keyword. That's the problem that a factory solves, with the trade-off that one introduces a tiny bit of overhead (in terms of execution). It is not just something you learn to impress during the interview, they're simply descriptions of a way to solve something. Lots of "developers" here would struggle with a undo/redo pattern, while others simply request a memento-pattern.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
MikeTheFid wrote:
I have referred to it and used patterns on only a few occasions since then. It never really caught on with me and became an automatic go-to while I'm at the design stage.
Because the reality is that most of those patterns have little usage in the vast mess that is implementation. Not to mention of course that singleton, which is the only one used a lot, tends to be used incorrectly a lot as well. So that didn't help much.
MikeTheFid wrote:
Do you use design patterns on a regular basis?
In the generic sense, not the book, yes.
MikeTheFid wrote:
If you use patterns regularly, do you have a source or sources of new patterns?
My head. And not as rigorously as GoF defines it. I looked at several of the follow on books to the GoF and found that most were really struggling to find patterns. That along with how seldom I had seen (even then) most of the patterns in the GoF didn't really bode well. Further experience seems to have supported my determination that although the idea was valid it just wasn't prevalent enough to attempt to normalize it.
jschell wrote:
Not to mention of course that singleton, which is the only one used a lot
The decorator is used throughout the .NET framework (streams), as well as the command-pattern, factories (DbFactory, ThreadFactory), strategy-patterns, object-managers..
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
jschell wrote:
Yes, but does that really relate to what GoF defines?
I'd seriously wouldn't know, I don't go there often :)
jschell wrote:
When you and/or the Architect says 'Factory' in a design discussion is the idea that it will follow, exactly, the first definition above?
No, just the generic idea, otherwise he would specify exactly what the requirements are. If he doesn't, then it is up to the developer to choose the most appropriate solution - which usually means going for the simplest thing possible (whilst still only returning an interface). ..but when in doubt, simply ask :thumbsup:
jschell wrote:
As for myself I am rather certain I follow neither. I expect that I use "Factory" to mean what GoF documents in the "Factory Method" to be 'ConcreteCreator' and I might use "Abstract Factory" in implementation (if I use it at all) as something that more closely resembles what "Factory Method" is. But not exactly.
Depends heavily on what is required; do you want a static factory, a singleton, or would you prefer an object? If it has to be combined with an object-manager pattern, then I'd think that the object is preferred. Do you want one object, or do you want multiple objects? In the first case, all objects created in the factory will be available over the manager globally. In the second case, only those objects are available that the specific factory created (in that thread). Point is, you don't want to explain how a "single point of creation in code" can save you from having to update a 1000 references in code where there's normally a "new"-keyword. That's the problem that a factory solves, with the trade-off that one introduces a tiny bit of overhead (in terms of execution). It is not just something you learn to impress during the interview, they're simply descriptions of a way to solve something. Lots of "developers" here would struggle with a undo/redo pattern, while others simply request a memento-pattern.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
jschell wrote:
Not to mention of course that singleton, which is the only one used a lot
The decorator is used throughout the .NET framework (streams), as well as the command-pattern, factories (DbFactory, ThreadFactory), strategy-patterns, object-managers..
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
All true, but in terms of the OP the specifics of what is in GoF doesn't seem to really have been all that useful useful.
Seems like a collection of formalized descriptions of some common patterns, but without much explanation. I don't think the website is meant as a source to learn those patterns; that is what their book is for :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Seems like a collection of formalized descriptions of some common patterns, but without much explanation. I don't think the website is meant as a source to learn those patterns; that is what their book is for :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
The "patterns" are out there and are being used; whether the "users" realize it or not. What did NOT happen, was that we'd all be sitting around "talking patterns" (like architects talking about "flying butresses" and the like). The odds of finding 2 people in the same room who CAN talk patterns is zero.
"(I) am amazed to see myself here rather than there ... now rather than then". ― Blaise Pascal
-
Quote:
The "patterns" are out there and are being used; whether the "users" realize it or not.
Patterns like the "copy/paste"- pattern and the "do it fast and Dirty"- pattern :laugh: