I have a horrible feeling I've been using a pattern for years...
-
Yes, it's called the "static cling" pattern as nothing put into the dictionary ever gets garbage collected. ;)
Latest Article - Class-less Coding - Minimalist C# and Why F# and Function Programming Has Some Advantages Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Global variables of any flavor have that problem, that's why I would only do something like that for things that remain mostly constant throughout the program's lifetime. Remember the Win32 hInstance parameter? It was passed to WinMain() as a parameter and remained unchanged from then on and you needed it for many Win32 API calls. The four bytes for a global variable were not much of a problem (yes, it was memory that was not cleaned up until the program ended) and it sure beats passing around that value to every window and dialog. When memory hogging is under control, state is not problematic (or even constant), and when I need it all over the place, I will not go through the trouble of routing that object or variable to the remotest parts of the application.
I have lived with several Zen masters - all of them were cats.
-
I use this when the instances are going to be resource heavy - maybe have a couple of images in them - and / or I want one example of each instance through the whole system. So I have a private constructor, a static Dictionary containing all created instances, and a static method which fetches the instance:
private static Dictionary all = new Dictionary();
private MyClass(string name, List data )
{
...
all.Add(name, this);
}
public static MyClass Get(string name, List data)
{
if (all.ContainsKey(name)) return all[name];
return new MyClass(name, data);
}And it works really well. But ... is that a pattern? I hope not, I might have to stop using it ... :~
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
A behavioral pattern?
Someone's therapist knows all about you!
-
OriginalGriff wrote:
Because most patterns are a waste of time, but worshipped as the One True Holy Grail of Computing by those that learn it. And then force all applications they write to fit that pattern regardless of the appropriateness.
..you are interacting with the wrong kind of people. Regardless of your silver bullet, I will not follow in the procession. "Most patterns"? Which are you referring to? They're used throughout the .NET Framework, from factories and adapters to decorators. Just my favourite, the memento, isn't included (afaik, which doesn't mean much). A pattern is simply a formalized piece of code that solves a problem. You have a list of those in your intellisense, don't you? Those snippets are formalized pieces of code that follow a specific pattern and that have a name. Now how does one take one of those templated pieces of code and make a holy grail of it? Is it some consultant, yammering to implement an event-receiver in C#? Code needs to be kissable clean; no patterns "just" to show of that you know something, the simplest solution is always the preferred one. But please, do follow the pattern of wrapping your connections and commands in a using-clause, do use parameterized queries, and please, use the factory-method that is included in the connection object to create your command. It saves a lot of time when rewriting to another provider. ..maybe I should just put my rambling in an article, as a lot of devs that I respect are not too fond of patterns for some weird reason. Tell me, do you vary your code to show a form, or does that happen to be another unnamed pattern that you repeat? :rolleyes:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
Eddy Vluggen wrote:
maybe I should just put my rambling in an article, as a lot of devs that I respect are not too fond of patterns
I am sure I would learn something valuable, if you did !
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
-
I use this when the instances are going to be resource heavy - maybe have a couple of images in them - and / or I want one example of each instance through the whole system. So I have a private constructor, a static Dictionary containing all created instances, and a static method which fetches the instance:
private static Dictionary all = new Dictionary();
private MyClass(string name, List data )
{
...
all.Add(name, this);
}
public static MyClass Get(string name, List data)
{
if (all.ContainsKey(name)) return all[name];
return new MyClass(name, data);
}And it works really well. But ... is that a pattern? I hope not, I might have to stop using it ... :~
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Interesting, Griff, I've played with some similar patterns. It probably was not your intent to show all of your code, but your mention of "heavy resources" made me wonder if you implement IDisposable, or the newer CLassName~ finalizer thingee.
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
-
It is the Tinder pattern. (A collection of singletons)
Duncan Edwards Jones wrote:
the Tinder pattern
That's a very tricky one since you have to implement your own MultiTassking, and MultiBedding.
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
-
Interesting, Griff, I've played with some similar patterns. It probably was not your intent to show all of your code, but your mention of "heavy resources" made me wonder if you implement IDisposable, or the newer CLassName~ finalizer thingee.
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
IDisposable - and needless to say there are ways to remove items from the
allcollection to prevent things gumming up the garbage collector.Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Eddy Vluggen wrote:
maybe I should just put my rambling in an article, as a lot of devs that I respect are not too fond of patterns
I am sure I would learn something valuable, if you did !
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
Yes, 10 novel ways to obfuscate your code and get a higher LOC :rolleyes: Working on it, and trying to make it usefull, instead of another summary on which pattern does what and whether it is creational or recriational.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
Yes, it's called the "static cling" pattern as nothing put into the dictionary ever gets garbage collected. ;)
Latest Article - Class-less Coding - Minimalist C# and Why F# and Function Programming Has Some Advantages Learning to code with python is like learning to swim with those little arm floaties. It gives you undeserved confidence and will eventually drown you. - DangerBunny Artificial intelligence is the only remedy for natural stupidity. - CDP1802
Marc Clifton wrote:
nothing put into the dictionary ever gets garbage collected.
Is there no way to handle that >?
«While I complain of being able to see only a shadow of the past, I may be insensitive to reality as it is now, since I'm not at a stage of development where I'm capable of seeing it.» Claude Levi-Strauss (Tristes Tropiques, 1955)
-
OriginalGriff wrote:
Because most patterns are a waste of time, but worshipped as the One True Holy Grail of Computing by those that learn it. And then force all applications they write to fit that pattern regardless of the appropriateness.
..you are interacting with the wrong kind of people. Regardless of your silver bullet, I will not follow in the procession. "Most patterns"? Which are you referring to? They're used throughout the .NET Framework, from factories and adapters to decorators. Just my favourite, the memento, isn't included (afaik, which doesn't mean much). A pattern is simply a formalized piece of code that solves a problem. You have a list of those in your intellisense, don't you? Those snippets are formalized pieces of code that follow a specific pattern and that have a name. Now how does one take one of those templated pieces of code and make a holy grail of it? Is it some consultant, yammering to implement an event-receiver in C#? Code needs to be kissable clean; no patterns "just" to show of that you know something, the simplest solution is always the preferred one. But please, do follow the pattern of wrapping your connections and commands in a using-clause, do use parameterized queries, and please, use the factory-method that is included in the connection object to create your command. It saves a lot of time when rewriting to another provider. ..maybe I should just put my rambling in an article, as a lot of devs that I respect are not too fond of patterns for some weird reason. Tell me, do you vary your code to show a form, or does that happen to be another unnamed pattern that you repeat? :rolleyes:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
I don't care for patterns in my code and I definitely don't care for vague terms like "clean" code. I only care for code that's short, safe to fail, easy to test, and understandable by a college freshman in less than 2 weeks. Nevertheless, please write about the patterns you think are worthwhile; preferably with a not-too-generic example. You might teach us something worthwhile. Also, if anyone knows of a must-read regarding the use of factory-pattern, please share. I really hate it and I'm looking for material to nuance my feelings towards it.
-
I use this when the instances are going to be resource heavy - maybe have a couple of images in them - and / or I want one example of each instance through the whole system. So I have a private constructor, a static Dictionary containing all created instances, and a static method which fetches the instance:
private static Dictionary all = new Dictionary();
private MyClass(string name, List data )
{
...
all.Add(name, this);
}
public static MyClass Get(string name, List data)
{
if (all.ContainsKey(name)) return all[name];
return new MyClass(name, data);
}And it works really well. But ... is that a pattern? I hope not, I might have to stop using it ... :~
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Seems like an Appalachian version of DI, just missing a banjo duel :)
But fortunately we have the nanny-state politicians who can step in to protect us poor stupid consumers, most of whom would not know a JVM from a frozen chicken. Bruce Pierson
Because programming is an art, not a science. Marc Clifton
I gave up when I couldn't spell "egg". Justine Allen -
I don't care for patterns in my code and I definitely don't care for vague terms like "clean" code. I only care for code that's short, safe to fail, easy to test, and understandable by a college freshman in less than 2 weeks. Nevertheless, please write about the patterns you think are worthwhile; preferably with a not-too-generic example. You might teach us something worthwhile. Also, if anyone knows of a must-read regarding the use of factory-pattern, please share. I really hate it and I'm looking for material to nuance my feelings towards it.
killbot5000 wrote:
understandable by a college freshman in less than 2 weeks.
If you can't explain your pattern in 5 minutes time, then you probably don't understand it. That is assuming that your freshman knows how to code :)
killbot5000 wrote:
Also, if anyone knows of a must-read regarding the use of factory-pattern, please share.
That's the pattern I'm opening the article with. May take another day or two.
killbot5000 wrote:
I really hate it
Yah, then you had the wrong explanation. Most important question to answer is always "what's in it for me?", and a factory has an easy to explain benefit :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I use this when the instances are going to be resource heavy - maybe have a couple of images in them - and / or I want one example of each instance through the whole system. So I have a private constructor, a static Dictionary containing all created instances, and a static method which fetches the instance:
private static Dictionary all = new Dictionary();
private MyClass(string name, List data )
{
...
all.Add(name, this);
}
public static MyClass Get(string name, List data)
{
if (all.ContainsKey(name)) return all[name];
return new MyClass(name, data);
}And it works really well. But ... is that a pattern? I hope not, I might have to stop using it ... :~
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
Hmm. I don't see anything wrong with it, other than the name "
all" for the container, which isn't terribly descriptive. I've used similar "patterns", where constructors and destructors maintain global constructs as a side effect. The global constructs usually simplify finding one of the instances in some way, or in accessing the entire collection of 'live' instances. In some cases I also use them for orderly shutdowns, to insure that all instances get destroyed properly. For what it's worth, I've never read the GoF Patterns book.Software Zen:
delete this; -
I use this when the instances are going to be resource heavy - maybe have a couple of images in them - and / or I want one example of each instance through the whole system. So I have a private constructor, a static Dictionary containing all created instances, and a static method which fetches the instance:
private static Dictionary all = new Dictionary();
private MyClass(string name, List data )
{
...
all.Add(name, this);
}
public static MyClass Get(string name, List data)
{
if (all.ContainsKey(name)) return all[name];
return new MyClass(name, data);
}And it works really well. But ... is that a pattern? I hope not, I might have to stop using it ... :~
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Because most patterns are a waste of time, but worshipped as the One True Holy Grail of Computing by those that learn it. And then force all applications they write to fit that pattern regardless of the appropriateness.
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
I was really wondering why you did not want to use a pattern so badly you would strike it from your code. I bought the GoF book, and was excited to be able to communicate better designs quicker. But, like you, I found zealots who used patterns like an indentation style. The could not code without them, and would convolute a simple program with them. I moved away from them, but use patterns (factory, most often) where they are clearly a solid approach, but NEVER worrying about doing it exactly as prescribed. But your comment felt like "I refuse to indent my code because there are indentation extremists"...
-
I use this when the instances are going to be resource heavy - maybe have a couple of images in them - and / or I want one example of each instance through the whole system. So I have a private constructor, a static Dictionary containing all created instances, and a static method which fetches the instance:
private static Dictionary all = new Dictionary();
private MyClass(string name, List data )
{
...
all.Add(name, this);
}
public static MyClass Get(string name, List data)
{
if (all.ContainsKey(name)) return all[name];
return new MyClass(name, data);
}And it works really well. But ... is that a pattern? I hope not, I might have to stop using it ... :~
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
And it works really well. But ... is that a pattern?
Yes. Multiton. Been around a long time. Multiton pattern - Wikipedia[^] The general idea is a Singleton per 'context' where the definition of the context is up the implementation.
-
I use this when the instances are going to be resource heavy - maybe have a couple of images in them - and / or I want one example of each instance through the whole system. So I have a private constructor, a static Dictionary containing all created instances, and a static method which fetches the instance:
private static Dictionary all = new Dictionary();
private MyClass(string name, List data )
{
...
all.Add(name, this);
}
public static MyClass Get(string name, List data)
{
if (all.ContainsKey(name)) return all[name];
return new MyClass(name, data);
}And it works really well. But ... is that a pattern? I hope not, I might have to stop using it ... :~
Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
A cunning way of asking a programming question in the Lounge! ;P The
allfield should bereadonly, since you never replace it. You should probably specify an explicitStringComparerfor the dictionary, to make it more obvious that the key is case-sensitive. I'd be inclined to move theAddto the static method, and leave the constructor alone. I'd also replace theContainsKey/ indexer pair with a singleTryGetValuecall:public static MyClass Get(string name, List<string> data)
{
if (!all.TryGetValue(name, out MyClass instance)
{
instance = new MyClass(name, data);
all.Add(name, instance);
}return instance;}
And as Gerry said, if there's any possibility of the method being called by multiple threads, use a ConcurrentDictionary[^] instead:
private static readonly ConcurrentDictionary<string, MyClass> all = new ConcurrentDictionary<string, MyClass>(StringComparer.Ordinal);
public static MyClass Get(string name, List<string> data)
{
return all.GetOrAdd(name, key => new MyClass(key, data));
}Let's hope your class doesn't contain any unmanaged or disposable resources, since you'd have no way of knowing when to clean them up. :-D
"These people looked deep within my soul and assigned me a number based on the order in which I joined." - Homer
-
killbot5000 wrote:
understandable by a college freshman in less than 2 weeks.
If you can't explain your pattern in 5 minutes time, then you probably don't understand it. That is assuming that your freshman knows how to code :)
killbot5000 wrote:
Also, if anyone knows of a must-read regarding the use of factory-pattern, please share.
That's the pattern I'm opening the article with. May take another day or two.
killbot5000 wrote:
I really hate it
Yah, then you had the wrong explanation. Most important question to answer is always "what's in it for me?", and a factory has an easy to explain benefit :thumbsup:
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
If you can't explain your pattern in 5 minutes time, then you probably don't understand it.
True enough. I was only trying to explain our somewhat informal guideline at work; a junior should be able to master any one of our projects in a maximum of 2 weeks time, without any help from a senior. In general, we don't trust juniors to correctly identify or implement various patterns, so we don't approach our code as such. But, of course, we do want juniors to be able to work for clients almost instantly. *grin* It's mostly an effort of gathering/vetting the right tools; ones that are easy to use, easy to test, and with a low code footprint. Around 90% of our R&D is spend on simplifying the way we do things. But, to come back to factory pattern: I hate it because it often seems the right choice, but, for me, it has never panned out. Every time I try it out, I end up over-designing my data models and adding an abstraction layer I don't really need. In the end, I usually remove it and end up with (almost embarrassingly..) simple classes with distinct data. It can be infuriating. I try to come up with a clever looking data structure, hope factory pattern fits the bill, and *boom* suddenly I see there's no need for abstraction whatsoever, vastly reducing my test code and simplifying my DB design. :(
-
If you can't explain your pattern in 5 minutes time, then you probably don't understand it.
True enough. I was only trying to explain our somewhat informal guideline at work; a junior should be able to master any one of our projects in a maximum of 2 weeks time, without any help from a senior. In general, we don't trust juniors to correctly identify or implement various patterns, so we don't approach our code as such. But, of course, we do want juniors to be able to work for clients almost instantly. *grin* It's mostly an effort of gathering/vetting the right tools; ones that are easy to use, easy to test, and with a low code footprint. Around 90% of our R&D is spend on simplifying the way we do things. But, to come back to factory pattern: I hate it because it often seems the right choice, but, for me, it has never panned out. Every time I try it out, I end up over-designing my data models and adding an abstraction layer I don't really need. In the end, I usually remove it and end up with (almost embarrassingly..) simple classes with distinct data. It can be infuriating. I try to come up with a clever looking data structure, hope factory pattern fits the bill, and *boom* suddenly I see there's no need for abstraction whatsoever, vastly reducing my test code and simplifying my DB design. :(
killbot5000 wrote:
Every time I try it out, I end up over-designing my data models and adding an abstraction layer I don't really need.
Might be easier to not try it until you need one. To find a scenario where the use of it would be beneficial, you'd need some decent example. The abstract examples didn't help me much.
killbot5000 wrote:
*boom* suddenly I see there's no need for abstraction whatsoever, vastly reducing my test code and simplifying my DB design. :(
KISS is always the best choice. Someone else will inderstand it better when reading, updates are easier and less complicated, and less code in general means fewer bugs. I'll give you a ping when I'm done and posted it :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I don't care for patterns in my code and I definitely don't care for vague terms like "clean" code. I only care for code that's short, safe to fail, easy to test, and understandable by a college freshman in less than 2 weeks. Nevertheless, please write about the patterns you think are worthwhile; preferably with a not-too-generic example. You might teach us something worthwhile. Also, if anyone knows of a must-read regarding the use of factory-pattern, please share. I really hate it and I'm looking for material to nuance my feelings towards it.
