About Abstract Classes?

URL: Link (1)

According to this wesbite .. you cannot implement Abstract classes but derive from them. This makes sense and I have read this many times.

Like an interface, you cannot implement an instance of an abstract class, how开发者_开发问答ever you can implement methods, fields, and properties in the abstract class that can be used by the child class.

But on MSDN

URL: TextWriter CLass on MSDN

TextWriter is an abstract class but it has two constructors defined ... and according to the MS 70-536 book, the following statement is valid:

TextWriter tw = new File.CreateText("myFile.Txt")

The static file class and it's CreateText method is fine by me as I have studied it on MSDN but can somebody explain this little contradiction I have found? Surely I am not the first?

Why is instantaion of base abstract classes possible?

The File.CreateText doesn't return a TextWriter, but a StreamWriter, which implements a TextWriter.

All abstract classes have at least one constructor - either you implement one or the compiler generates a parameterless default constructor. The constructor is executed when a derived class is instantiated - it does not matter that the base class is abstract.

But you cannot instantiate an abstract class - File.CreateText() is a static method and returns an instance of a class derived from TextWriter but not a TextWriter instance.

You can instantiate what seems to be an abstract class here for the same reason you can instantiate what seems to be an interface: You're not actually creating a class of that type, but creating a class that can be cast to that type. tw can be defined as a TextWriter, though it could not actually be a TextWriter.

However, I'm suspicious of the new keyword. Are you sure that works? It shouldn't. File.CreateText creates and returns (something that inherits from) a TextWriter, but new indicates a constructor, which is not what's happening.

The implementation of File.CreateText is creating and returning a type that is a concrete implementation of TextWriter. I.e. Whatever type is returned is-a TextWriter -- it's not some magical instantiation of an abstract class.

Although you cannot create an abstract class, you can refer to it an instance of a derived type by its base type without a problem. If you couldn't do this, then polymorphism would be pretty useless!

Magic of polymorphism/inheritance.

File.CreateText returns a StreamWriter, which inherits from TextWriter.

It's not possible.

What's happening (once you remove the new keyword to make the code work at all) is that the CreateText method is creating an instance of StreamWriter, which inherits TextWriter. The StreamWriter reference is assigned to a TextWriter variable, which is valid because a StreamWriter is a TextWriter.

The reason that an abstract class has constructors is to initialise the data in the abstract class. The constructor can't be used directly, but it will be called by the constructor in the class that inherits the abstract class.

CreateText returns a StreamWriter

public static StreamWriter CreateText(string path)

StreamWriter is a subclass of TextWriter and thus can be stored in the TextWriter variable. The example is using the abstract class because it does not care about the real implementation of what it is writing the text to.