Tài liệu Abstract Classes ppt

Abstract Classes
The IToken interface could be implemented by many different classes, one for each type
of token in a C# source file: IdentifierToken, KeywordToken, LiteralToken,
OperatorToken, and PunctuatorToken. (You might also have classes for comments and
white space.) In situations such as this, it's quite common for parts of the derived classes
to share common implementations. For example, the duplication in the following two
classes is obvious:
class IdentifierToken : IToken
{
public IdentifierToken(string name)
{
this.name = name;
}

public virtual string Name()
{
return name;
}

private string name;
}

class StringLiteralToken : IToken
{
public StringLiteralToken(string name)
{
this.name = name;
}

public virtual string Name()
{
return name;
}

private string name;
}
Duplication in code is a warning sign. You should refactor the code to avoid the
duplication and reduce any maintenance costs. However, there is a right way and a wrong
way to do this. The wrong way is to push all the commonality up into the interface. This
is wrong because you'd then have to change the interface to a class (because an interface
can't contain any implementation). The right way to avoid the duplication is to refactor
the common implementation into a new class created specifically for this purpose. For
example:
class DefaultTokenImpl
{
public DefaultTokenImpl(string name)
{
this.name = name;
}

public string Name()
{
return name;
}

private string name;
}

class IdentifierToken : DefaultTokenImpl, IToken

{
public IdentifierToken(string name)
: base(name)
{
}

}

class StringLiteralToken : DefaultTokenImpl, IToken
{
public StringLiteralToken(string name)
: base(name)
{
}

}
This is a good solution, but there is one thing that is still not quite right: You can create
instances of the DefaultTokenImpl class. This doesn't really make sense. The
DefaultTokenImpl class exists to provide a common default implementation. Its sole
purpose is to be inherited from. The DefaultTokenImpl class is an abstractration of
common functionality rather than an entity in its own right.
NOTE
If you find the situation with the DefaultTokenImpl class confusing, consider the
Mammal, Horse, Whale, and Kangaroo example shown earlier. Mammal is a classic
example of an abstract class. In the real world, you may see horses, whales, and
kangaroos trotting, swimming, or bouncing around, but you will never see a “mammal”
doing any of these things. Mammal is simply a convenient abstraction for classifying the
actual animals.
To declare that you're not allowed to create instances of a class, you must explicitly
declare that the class is abstract, by using the abstract keyword. For example:

abstract class DefaultTokenImpl
{
public DefaultTokenImpl(string name)
{
this.name = name;
}

public string Name()
{
return name;
}
private string name;
}
Notice that the new class DefaultTokenImpl does not implement the IToken interface. It
could, but the IToken interface doesn't really fit with its purpose. An abstract class is all
about common implementation, whereas an interface is all about usage. It's usually best
to keep these two aspects separate, and to let the non-abstract classes (such as
StringLiteralToken) determine how to implement their interfaces:
• They can inherit from DefaultTokenImpl and IToken, in which case
DefaultTokenImpl.Name becomes the implementation of IToken.Name. Notice
that this means DefaultTokenImpl.Name must be public. You could make the
constructor for DefaultTokenImpl protected, but the Name method must remain
public if it is to qualify as an implementation of IToken.Name in a derived class.
• They can decide not to inherit from DefaultTokenImpl, in which case they'll have
to implement IToken.Name themselves.