Why static classes?
-
I am creating an app to interrogate a web-site. In combing through the examples on MSDN and elsewhere to learn about socket programming, I noticed that almost all the examples have static classes and methods. What is the reason for this? In my case, I am indifferent. For a variety of reason out of my control, this will be a single threaded query/reply app. Is there some performance issue involved? It would be easier to not have to declare/manage variable representing the classes. Is that why it is done? :confused:
-
I am creating an app to interrogate a web-site. In combing through the examples on MSDN and elsewhere to learn about socket programming, I noticed that almost all the examples have static classes and methods. What is the reason for this? In my case, I am indifferent. For a variety of reason out of my control, this will be a single threaded query/reply app. Is there some performance issue involved? It would be easier to not have to declare/manage variable representing the classes. Is that why it is done? :confused:
Most handy for classes that contain only library routines. Otherwis, a regular class is probably more appropriate even if you intend to never have more than one instance.
-
I am creating an app to interrogate a web-site. In combing through the examples on MSDN and elsewhere to learn about socket programming, I noticed that almost all the examples have static classes and methods. What is the reason for this? In my case, I am indifferent. For a variety of reason out of my control, this will be a single threaded query/reply app. Is there some performance issue involved? It would be easier to not have to declare/manage variable representing the classes. Is that why it is done? :confused:
Generally you only use static classes for stateless methods. There are also singletons, and it is generally considered good practice to access singletons through and static instance property which will instantiate the singlton class if it has not already in instantiated when the instance property is first called.
-
I am creating an app to interrogate a web-site. In combing through the examples on MSDN and elsewhere to learn about socket programming, I noticed that almost all the examples have static classes and methods. What is the reason for this? In my case, I am indifferent. For a variety of reason out of my control, this will be a single threaded query/reply app. Is there some performance issue involved? It would be easier to not have to declare/manage variable representing the classes. Is that why it is done? :confused:
-
mjackson11 wrote:
Is there some performance issue involved?
Yes. Removes the need to lookup the object-instance.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Sure, but that's no reason to use a static class when a regular class is more apropriate.
-
Sure, but that's no reason to use a static class when a regular class is more apropriate.
And vice versa; a static class would be appropriate. What's the use of a singleton-pattern if all it does is replace a static class, without adding any additional value?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
-
And vice versa; a static class would be appropriate. What's the use of a singleton-pattern if all it does is replace a static class, without adding any additional value?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
I don't recommend the Singleton-pattern either. One of the things I had to work around in the last year is that the System.Console class is static -- I needed a non-static class I could pass around so I had to wrap System.Console in another class, it was dreadful. The problem is worse because .net doesn't have Interfaces for TextReader and TextWriter. :mad: I had to create those as well. Making a class static or Singleton simply because you don't expect to ever need more than one is not a good idea; don't limit your options unnecessarily.
-
I don't recommend the Singleton-pattern either. One of the things I had to work around in the last year is that the System.Console class is static -- I needed a non-static class I could pass around so I had to wrap System.Console in another class, it was dreadful. The problem is worse because .net doesn't have Interfaces for TextReader and TextWriter. :mad: I had to create those as well. Making a class static or Singleton simply because you don't expect to ever need more than one is not a good idea; don't limit your options unnecessarily.
Why pass a static class around in the first place? There's no need to pass a reference if there's only one class.
PIEBALDconsult wrote:
Making a class static or Singleton simply because you don't expect to ever need more than one is not a good idea; don't limit your options unnecessarily.
I'd expect an app to have a single stdout. Did you have multiple?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
-
Why pass a static class around in the first place? There's no need to pass a reference if there's only one class.
PIEBALDconsult wrote:
Making a class static or Singleton simply because you don't expect to ever need more than one is not a good idea; don't limit your options unnecessarily.
I'd expect an app to have a single stdout. Did you have multiple?
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] They hate us for our freedom![^]
Eddy Vluggen wrote:
if there's only one class
But there might not be!
Eddy Vluggen wrote:
a single stdout
That's not the point. I want to pass a reference to something that implements ITextWriter, for example, I don't care that it just happens to be System.Console in this particular case. But .net doesn't allow me to do that easily for multiple reasons.