In situations such as this, it's quite common for parts of the derived classes to share common implementations.. The right way to avoid the duplication is to refactor the common implemen
Trang 1Abstract 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
Trang 2way 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
Trang 3purpose 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