|
Thanx a lot... Still, you recommended not to use Singleton. Why?
--
Varun
|
|
|
|
|
They're silly. I've never yet found a reason to use one. They seem to solve a problem that doesn't exist. They limit your future options. They were devised prior to C# -- in C# (since V2) a static class may be a better fit, otherwise just use a regular class.
At any rate, if you do write a Singleton (and I can't stop you), follow Skeet's advice.
|
|
|
|
|
i would like to hear more about why singleton are silly... I've a case where a server application would manage a list of users, the server could add a user, getLoggedUsers, log a user in, log out a user, get a list of all users and contact one user to send a chat request (the client contacts the server about the chat request, the server alerts the target user and then the users would chat directly), to implement the functionality of the contacts list (not a simple List<user>, sadly) i've made a static class who controls the underling List, synchronizing it with a XML file (used to serialize the list), this way, all the users contacting the server would see the same list of users.
i was thinking in replacing the static class with a singleton, you think it's a bad idea?
i would appreciate your opinion.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Sentenryu wrote: i was thinking in replacing the static class with a singleton, you think it's a
bad idea?
Mainly I just don't see the point. Does it work as a static class? What do you think a Singleton would provide that a static class doesn't? If the users are running in different systems then they wouldn't share the Singleton anyway -- and if it's behind a Service then it's just a black box so what difference does it make to the clients?
If you've read up on the Singleton Pattern, then you should know that it provides a shared instance -- if it isn't going to be shared, then it probably isn't the right tool for the job. Nor am I sure that a static class is either; I'd likely just instantiate one instance of a regular class.
When I wrote a chat system, it had a database and each client connected to the database server to log in/out, get the list of users, send/get messages, etc. -- I haven't gotten around to writing a Web Service for it yet, and haven't experimented with Web Services at all for two years. But I wouldn't automatically run off and write a Singleton to hide behind the Service.
|
|
|
|
|
this "chat" is a submission to my university, i can't use a database and need to user a server application that communicates witch tcp/ip (if i can use a database, this wouldn't be a problem  )
in theory it works with the static class, the problem is that i'm afraid it's not safe, what happens if two users connected (so, two threads) request the server to add a new user, then the server call the Add method 2 times simultaneously, the Add method writes a XML file and then reads it again (yes, poor implementation, hopefully not mine).
the point in making it a static class is that in this way all the threads would have access to the same list of users, but i've seen very strange comportment of this class, in the static constructor, the class instantiate and fills the list of contacts, i've put a breakpoint here and tested, for some reason, when i called the add method, the static constructor was not executed, with scared the sh*t out of me, everything was null, then, when the method returned (the method executed with success, even with the List<users> null, they were able to add to it, i don't know how) then the execution point moved to the static constructor, in my breakpoint.
after much test, i've found that when 2 threads call a method of this class, the secund call execute before the static constructor, i think it's a bug with my installation of visual studio, i prefer not to consider that this can occur i in a production environment, but just in case...
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Sentenryu wrote: in theory it works with the static class, the problem is that i'm afraid it's
not safe, what happens if two users connected (so, two threads) request the
server to add a new user, then the server call the Add method 2 times
simultaneously, the Add method writes a XML file and then reads it again (yes,
poor implementation, hopefully not mine).
That question has nothing to do with whether it is a singleton or not.
Sentenryu wrote: but i've seen very strange comportment of this class
That has nothing to do with the correct behavior of the class. Could be something odd with how you were using the debugger, could be mismatch in classes, could bug in your code or something even more exotic like a bug in the debugger.
I wouldn't get to wrapped up in the implementation of the idea of a singleton.
Conceptually a singleton is a representation of a single instance of a class. Nothing magical about that. You can use a static class to manage the access to a single instance (a different class) without strictly implementing the singleton pattern and yet still conceptually implement it.
|
|
|
|
|
Sentenryu wrote: submission to my university
If it's classwork, then considering and trying out different ways of implementing it is a good thing. 
Sentenryu wrote: if two users connected (so, two threads)
My understanding is that if they're in separate App Domains, then a Singleton won't help anyway -- each would have its own instance. And that would be true of a static class as well. You may need to look into a Mutex, which is sort of like the locking object, but system-wide.
|
|
|
|
|
now you have confused me, the console application that acts as the server is the only one who will use this class, what will be sent to the client is a xml response of their request. the threads are created in the server with a ThreadPool (subject to change, i think i'm using the wrong class, maybe i'm confusing it with java's ThreadPool...) in my understanding, all of those threads run in the App Domain of the console application, is this wrong?
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Sentenryu wrote: all of those threads run in the App Domain of the console application
Oh, yes, but then why do you have threads?
Sentenryu wrote: the console application
The main method of which is static already, so I'd likely stick with static.
Hmmm... so, if I understand what you're saying, each client makes a connection to the Server and gets its own thread, which I suppose is a session, and it continues to interact with the server that way until it disconnects?
I'm not sure that's a good architecture*, but not being an expert on that sort of thing, I'd better keep quiet and let others provide guidance.
* I'm fairly sure that a "connectionless" technique is more robust.
|
|
|
|
|
i'm just very bad in English =p
there's no logical connection from the client to the server, the client just sends a request and the server responds, after the response, there's no more link between the client and the server, the threads are used so the server can serve more than one client at a time.
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
PIEBALDconsult wrote: What do you think a Singleton would provide that a static class doesn't?
The ability for the singleton to be passed as a parameter.
/ravi
|
|
|
|
|
Yes, but you're not supposed to do that with a Singleton -- being a Singleton means you don't have to pass it, all parts of the system know where to get it:
"Provide a global point of access to the object."
|
|
|
|
|
There are cases where we can have different singletons, all of which implement an interface IFoo (for example) and a method that has accepts an IFoo parameter. Due to separation of concerns, the method may have no idea about the existence of the concrete singletons. For example:
static class PrettyPrinter
{
public static string PrettyPrint
(string textToBePrettyPrinted,
IPrettyPrinterRuleProvider rulesToUse)
{
...
return prettyPrintedString;
}
}
...
string text = "...";
string result1 = PrettyPrinter.PrettyPrint (text, KAndRTypeFormattingRules.Instance);
string result2 = PrettyPrinter.PrettyPrint (text, MicrosoftFormattingRules.Instance);/ravi
|
|
|
|
|
Well sure, but would you design a class to do that with and make it a Singleton? Why? I see no reason to do so.
Look at, perhaps, System.StringComparer and its fields.
|
|
|
|
|
PIEBALDconsult wrote: make it a Singleton? Why?
For performance reasons. I would prefer to not have to new up a concrete IPrettyPrinterRuleProvider each time I call PrettyPrinter.PrettyPrint().
/ravi
|
|
|
|
|
And you don't; nor does it need to be a Singleton. It can be a static field of the class, for instance.
|
|
|
|
|
Yes, but that would cause unneccesary coupling.
I'm not suggesting singletons are absolutely necessary (heck even while, for, switch and continue statements aren't!). My point is the singleton pattern (especially when combined with Lazy<T>) allows one to write more performant and more manageable code.
/ravi
|
|
|
|
|
Ravi Bhavnani wrote: that would cause unneccesary coupling.
I don't think so.
Ravi Bhavnani wrote: one to write more performant and more manageable code.
Bullpuckey.
|
|
|
|
|
Ravi Bhavnani wrote: For performance reasons. I would prefer to not have to new up
a concrete IPrettyPrinterRuleProvider
There is design, implementation and performance. Distinct but interrelated idioms.
You would NEVER impose a design limit based solely on creating an instance. You MIGHT impose a design limit based on the work that creating an instance requires. That however is very, very rare. (I am specifically referring to creating the instance.)
And I suspect for your example it does not apply.
In terms of measuring (actual values) the performance of an application if you find that a specific bit of code imposes a performance bottleneck on the application (not a just a hunk of code) then you modify the implementation to correct that. If you must modify the design to correct a measured performance problem then you have a bug in the design which requires a rework of the design and implementation.
The factors the lead to a redesign where the ONLY problem is a performance problem is probably very rare. Typically if someone cannot anticipate a performance problem at the design level then the design is incomplete or the designer does not have enough experience and thust the entire design is questionable.
|
|
|
|
|
The biggest problem with singletons lies in the fact that it reduces parallelism. As you only have a single instance present, any threaded operations must be serialized in and out of the singleton, reducing the efficiency of the threading. They can also make it harder to unit test code because it can introduce global state.
|
|
|
|
|
i see, this really helps, in my case I've global state (the list of users), and i've to synchronize the access, so this wont help... i think i'll just rewrite this to use normal instances and a single shared user list, apparently, is the best solution at the moment, i'm working on this with a plenty of beginners and the only thing that will be sent to the appraiser, thanks
I'm brazilian and english (well, human languages in general) aren't my best skill, so, sorry by my english. (if you want we can speak in C# or VB.Net =p)
|
|
|
|
|
Pete O'Hanlon wrote: The biggest problem with singletons lies in the fact that it reduces
parallelism. As you only have a single instance present, any threaded operations
must be serialized in and out of the singleton, reducing the efficiency of the
threading. They can also make it harder to unit test code because it can
introduce global state.
I don't agree.
The biggest problem with singletons is incorrect usage and from that overusage.
For your points...
For the first problem sometime the very nature of the need dictates serialization anyways. And in other cases there are ways that can allow multiple access.
As for the second problem there are trivial solutions for most problems of that nature, for example just implementing a Reset() method.
|
|
|
|
|
jschell wrote: For the first problem sometime the very nature of the need dictates
serialization anyways.
In that case, you shouldn't be parallelising the code at this point. This concern was raised specifically for the case where you have a parallel architecture that has to be throttled because of a singleton.
jschell wrote: As for the second problem there are trivial solutions for most problems of that
nature, for example just implementing a Reset() method.
So, we're talking about introducing a method just to get through a test; not for any other purpose.
I think you misunderstood my point. I wasn't arguing that you should never use a singleton; I was just showing what the weaknesses are. If you are comfortable that you understand the pattern sufficiently well, and that you know exactly how your code is going to be used, then you can make an informed decision. If you don't know what the weaknesses are, then you can end up causing all sorts of problems for yourself.
|
|
|
|
|
Pete O'Hanlon wrote: In that case, you shouldn't be parallelising the code at this point. This
concern was raised specifically for the case where you have a parallel
architecture that has to be throttled because of a singleton.
Not sure what you are referring to.
I took your response to suggest that you were addressing the Singleton Pattern, and not one specific instance of that.
Pete O'Hanlon wrote: So, we're talking about introducing a method just to get through a test; not for
any other purpose.
Yep.
|
|
|
|
|
They artificially restrict your ability to change your mind later, and don't really provide any benefit. You can always just instantiate one copy of an object if you only need one!
If you have a need for a single static instance of some stuff, have a static reference to it.
static class GlobalData {
public static ContactListManager ContactListManager { get; private set; }
static GlobalData(){
ContactListManager = new ContactListManager("datastore.xml");
}
}
That way, if you discover that you want to manage disparate contacts across several data sources and therefore it shouldn't be a singleton any more, it's much easier to change. It means that if you want a temporary separate instance for some reason (e.g. importing external data), you can do so.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
