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. . Abstract Classes The IToken interface could be implemented by many different classes, one for each type of token. class, you must explicitly declare that the class is abstract, by using the abstract keyword. For example: abstract class DefaultTokenImpl { public DefaultTokenImpl(string