tags:

views:

88

answers:

3

Hello, I hope I understood the concept of static classes (thanks to Jon Skeet and his answer on my other question). Also, I am only intersted why on MSDN they do not show Console as typical static class. Or is Console something special in this way?

+2  A: 

Console is a static class. There can only be one Console per application. When you call methods on the Console class, that single Console class is used. Same is true for any static type or static member . Static-anything cannot have multiple instances within the same app/app-domain.

mumtaz
Yes, that was what I thought. I think its more illustrative than examples on MSDN.
Ptr
@Ptr... on MSDN they sometimes talk to someone else, not to you and me :)
mumtaz
What about the things on MSDN suggests that `System.Console` is not static?
Andrew Barber
@Adrew ... Ptr was complaining about Console class not being mentioned as a typical example of static types. He is not saying that its not declared as static.
mumtaz
@Adrew:I am not saying it is not static. Actually, I wrote it seems to me to be ideal static class which can be used for explanation.
Ptr
A: 

In case you are asking "why isn't it a static class" - it is a static class:

public static class Console

But if you're asking, why isn't it used as a useful example of a static class:

.. why on MSDN they do not show Console as typical static class ...

The basic API documentation (including that for the Console class) on MSDN focuses on the mechanics of each feature, and a small example of the syntax and code that you could write to use the feature. It describes the facilities provided by each feature or class. It describes the programming contracts, including the namespace and assemblies that the feature depends on, lists of members, return values, expected ranges of input, error handling, and parent classes in inheritance hierarchy.

This documentation does not tend to focus on how each feature fits in the ecosystem of programming architecture, or programming best practices. It often doesn't mention alternative options, or trade-offs made by choosing to use the feature. Indeed, many samples in the API documentation are examples of bad programming practices, and some of them don't even compile.

There are other areas on MSDN that cover architectural concerns, programming best practices, and examples of why a feature was useful to the .NET framework (e.g. Safe Handles, and the Dispose pattern). Maybe you simply haven't found (or there isn't) an article relating to static classes, their uses, and existing examples in the framework?

Addressing this lack though, it sounds like this could be a useful article, especially if it digs into bad practices that are easily fallen into when programming with static classes (strong coupling, difficulty in testing them, and difficulty implementing concurrency).

Merlyn Morgan-Graham
A: 

System.Console was not initially declared as static because it exists since .NET 1.1, which did not support static classes, only static members.

Frédéric Hamidi