Why are abstract classes needed?

Possible duplicate:
What is an abstract class?

1. What is the point of creating a class that cannot be created?

Most often used as a base class or interface (some languages ​​have a separate interface construct and some don't) - it doesn't know the implementation (which should be provided by the subclass / implementation classes)

2. Does anyone want such a class?

For abstraction and re-use

      

3. What is the situation when abstract classes become NECESSARY? Can anyone describe this with an example?

+2


a source to share


5 answers


They are not the abstract class that is always needed, but they are often quite handy. Let's say I want to write a parser for a specific type of text file.

// hasty code, might be written poorly
public abstract class FileParser<T> {
    private readonly List<T> _contents;
    public IEnumerable<T> Contents {
        get { return _contents.AsReadOnly(); }
    }

    protected FileParser() {
        _contents = new List<T>();
    }

    public void ReadFile(string path) {
        if (!File.Exists(path))
            return;

        using (var reader = new StreamReader(path)) {
            while (!reader.EndOfStream) {
                T value;
                if (TryParseLine(reader.ReadLine(), out value))
                    _contents.Add(value);
            }
        }
    }

    protected abstract bool TryParseLine(string text, out T value);
}

      



After choosing something like the above, I ended up with a pattern of code that any FileParser

-esque class would need. All I would have to do for any derived class is simply to override one abstract method - TryParseLine

- and not write the same tedious stuff about threads etc. Also, I could easily add functionality later - such as exception handling - and it will apply to all derived classes.

+6


a source


Abstract classes allow you to write a common piece of code that defers specific decisions to derived classes, thereby reducing code duplication.



+5


a source


You (probably) need abstract classes when creating a single ancestor inheritance tree that cannot be created simply because you don't know how some of the methods can be implemented.

Marking a class as abstract tells the compiler about:

  • Example 1
    If you need a single ancestor for Car

    and Bicycle

    , you probably create a class Vehicle

    . You cannot initiate this class Vehicle

    because it is incomplete. A Vehicle

    itself will not work. Therefore, it Vehicle

    will be abstract.

  • Example 2
    Another example from the .Net framework. A class Stream

    is an abstract class that provides basic I / O functionality. It provides a read and write method for handling bytes in the litter stream.

This stream may be FileStream

, NetworkStream

, MemoryStream

, etc. Itself Stream

does not know how to read or write from a concrete stream implementation. But some of the methods are Stream

implemented because they are shared by all instances of the stream.

It cannot be done with an interface. Therefore, you need to create a class. Since methods Read

and Write

cannot be implemented, it is Stream

marked as abstract. This will prevent the Stream

as-is class from being created .

+4


a source


Abstract classes are never needed strictly. You can always use a non-abstract class and provide stubs for methods that were otherwise abstract. You can also approximate aspects of the abstract by exposing the class to protected constructors only.

But that's not the point. When a class is used to model the generic properties and behavior of a group of subclasses, you want to mark it abstract to make your intent clear.

+2


a source


I know that I need to save information between moments of my application.

I know what methods I need for this. I can also provide several methods that perform different parts of the overall storage operation.

I know my clients have different storage requirements based on preference (MS Sql, Oracle) and laws (industry security requirements).

How can I provide an object that does 80% of the hard work but leaves the last 20% open for customization?

An abstract base class allows us to customize the last 20% for each client, but reuse 80% of the common code in the base class. Plus, abstract classes don't suffer from issues with versions that interact with the face , which is a bonus.

I can code my application, provide standard abstract base class implementations, test and deploy without having a separate version for each client. Since clients request different storage methods, a different implementation can be provided and used at runtime via dependency injection .

+2


a source







All Articles