When and Why to use abstract classes/methods?

I have some basic questions about abstract classes/methods. I know the basic use of abstract classes is to create templates for future classes. But are there any more uses for them? When should you prefer them over interfaces and when not? Also, when are abstract methods useful?

> I know the basic use of abstract classes > is to create templates for future > classes. But are there any more uses > of them?

Not only can you define a template for children, but Abstract Classes offer the added benefit of letting you define the functionality that your child classes can utilize later.

You could not provide a default method implementation in an Interface prior to Java 8.

> When should you prefer them over > interfaces and when not?

Abstract Classes are a good fit if you want to provide implementation details to your children but don't want to allow an instance of your class to be directly instantiated (which allows you to partially define a class).

If you want to simply define a contract for Objects to follow, then use an Interface.

> Also when are abstract methods useful?

Abstract methods are useful in the same way that defining methods in an interface is useful. It's a way for the designer of the Abstract class to say "any child of mine MUST implement this method".

read the following article http://mycodelines.wordpress.com/2009/09/01/in-which-scenario-we-use-abstract-classes-and-interfaces/

> Abstract Classes > > –> When you have a requirement where > your base class should provide default > implementation of certain methods > whereas other methods should be open > to being overridden by child classes > use abstract classes. > > For e.g. again take the example of the > Vehicle class above. If we want all > classes deriving from Vehicle to > implement the Drive() method in a > fixed way whereas the other methods > can be overridden by child classes. In > such a scenario we implement the > Vehicle class as an abstract class > with an implementation of Drive while > leave the other methods / properties > as abstract so they could be > overridden by child classes. > > –> The purpose of an abstract class is > to provide a common definition of a > base class that multiple derived > classes can share. > > For example a class library may define > an abstract class that is used as a > parameter to many of its functions and > require programmers using that library > to provide their own implementation of > the class by creating a derived class. > > Use an abstract class > > When creating a class library which > will be widely distributed or > reused—especially to clients, use an > abstract class in preference to an > interface; because, it simplifies > versioning. This is the practice used > by the Microsoft team which developed > the Base Class Library. ( COM was > designed around interfaces.) Use an > abstract class to define a common base > class for a family of types. Use an > abstract class to provide default > behavior. Subclass only a base class > in a hierarchy to which the class > logically belongs.

At a very high level:

Abstraction of any kind comes down to separating concerns. "Client" code of an abstraction doesn't care how the contract exposed by the abstraction is fulfilled. You usually don't care if a string class uses a null-terminated or buffer-length-tracked internal storage implementation, for example. Encapsulation hides the details, but by making classes/methods/etc. abstract, you allow the implementation to change or for new implementations to be added without affecting the client code.

Abstract classes/methods are generally used when a class provides some high level functionality but leaves out certain details to be implemented by derived classes. Making the class/method abstract ensures that it cannot be used on its own, but must be specialized to define the details that have been left out of the high level implementation. This is most often used with the template method pattern:

http://en.wikipedia.org/wiki/Template_method_pattern

Typically one uses an abstract class to provide some incomplete functionality that will be fleshed out by concrete subclasses. It may provide methods that are used by its subclasses; it may also represent an intermediate node in the class hierarchy, to represent a common grouping of concrete subclasses, distinguishing them in some way from other subclasses of its superclass. Since an interface can't derive from a class, this is another situation where a class (abstract or otherwise) would be necessary, versus an interface.

A good rule of thumb is that only leaf nodes of a class hierarchy should ever be instantiated. Making non-leaf nodes abstract is an easy way of ensuring that.