Why we need abstract class when we can inherit normal class?

Question

Possible Duplicate:
Interface vs Abstract Class (general OO)

Following are the confusions which I have between interface, abstract and normal class-

1. I know an abstract class can have a method with no implementation, but what is the harm in declaring method as virtual in base class with some dummy implementation and over ride in derived class. Looking for a practical scenario where answer can be validated?

2. Why we need an interface when we have abstract class, I know with interface we can have multiple inheritance, and have goggled about various theoretical reasons, looking for practical scenarios where abstract class just cant help and you have to go for interface?

3. Is having an abstract class and interface is not an overhead?

Answer 1

Practical Examples

I think you are thinking too hard. Its like looking at a fork and a spoon and worrying about when to use when. There is no right answer, just use the one that makes sense to you for what you are doing. Many paths to getting there.

Here is how I use these in the real world (fortune 500 companies etc...)

Interfaces allow you to add as many as you want to a class. They essentially allow you to bind to any contract as much as you want. They are as minimal as you get. An example I used this in was a music encoder service where it just had some simple properties and methods that each encoder type needed. I later added more interfaces as other requirements came into play but I didn't want to break the code for other parts not needing to know or care about the new interface. The encoders were very loosely coupled and could have more than one contract so this made sense for me. The main thing about interfaces is when you use them, don't keep changing them as it defeats the purpose of the interface, rather make a new one. Interfaces are the best for plugin type of development.

Abstract classes are kind of cool because you can have some base implementation already cooked in there but you are essentially saying "but you still have to make this part" as its the responsibility of the class to implement this. This could be for a "save" method for example. Let's say you had some abstract class that handled data in the same way but you had many commonalities in the underlying abstract class that did a lot of work but you had a requirement that each inherited type save its own data in its own format needed for example. This could relate to a networked item that saved things in facebook and twitter or another item that saved things in a database and a file system but the core code always hit a central db to say it was saved with last date modified.

So sorry, I was bored, lots of typing. But that's how I have used them.

Answer 2

1. There are scenarios where there is no "correct" dummy implementation. In the System.IO.Stream case (an abstract class), for example, what would be a reasonable implementation for Read or Write? Throw? Do nothing? Or the many methods in the System.Xml.XmlReader class - what's a reasonable implementation for a Depth, or Read of an arbitrary XML reader? By making methods in a class abstract (and not virtual) the author of the class is making a statement that anyone who derives from that class must think about what to do for those methods, and the abstract qualifier enforces that.

2. The practical reason is exactly what you said - multiple inheritance. If IEnumerable<T> were an abstract class, for example, there would be many cases where we'd want to be able to enumerate over the elements of an object but couldn't because the object already inherited from some other class. The more theoretical reason is that interfaces usually define behavior, while classes define a cluster of objects, but for the purposes of your question the practical reason is more, well, practical.

3. I don't understand your question. Overhead in which sense?

Answer 3

Each has its own purpose. You use an interface when you don't want to define any specific implementation. It only provides an "interface" to an object, that is the methods and properties that make up a public definition. An object can inherit multiple interfaces. A good example of this is the List<> object. List<> implements several interfaces, such as IEnumerable, IList, ICollection, IEnumerable<>, IList<>, and ICollection<>.

Each of these has different methods, and different properties, and are used for different purposes. You could not do this with an abstract class. You can cast a List<> to any of those interfaces and use them without knowing the exact implemenation of them. This is particularly useful with a concept known as Dependency Injection, but has many other uses.

An abstract class is useful when you want to define part of the implementation of an object, but want to leave other parts up to the derived class. One key thing to remember about abstract classes is that they cannot be instantiated by themselves, because they typically lack a complete implementation as well as the fact that abstract keyword tells the complier it can't be instantiated. Yes, you can supply dummy implementations, but why? The whole point is that abstracts are.. well.. abstract.

Imagine you have a class Cat, and this class derives from a class Animal. There is no such thing as an Animal object, it's just a "type". You can't instantiate an Animal because there is no actual Animal in the real world, there are only creatures that are of the type Animal. You can treat different creatures as a common Animal type, but there can't exist a real Animal, it's just a concept.

An Animal would be an abstract type, because the concept of the Animal is abstract. The same is true in software. You might have the concept of an object, such as a Stream. Is it a NetworkStream? A FileStream? A MemoryStream? Stream is just a concept. An interface is also just a concept, but the unlike an abstract class an Interface cannot have any implementation.

So think of an abstract class as a concept with some implementation, and an interface as a concept without any implementation.