Inheritence or Abstract class

[deepak carter]

HI all,

can anyone let me know real time example when to use Inheritence and when to use abstract class??

[Rinkit Shah]

You will use Inheritance when you find some common kind of features to be put into one, lets say for example CAR class has super car,town car ,etc. Some basic functionality you can put into CAR class and other things which are specific to say super car you can put into SUPERCAR class similar with other cars.


Same thing is with abstract class the only difference is say every CAR has an engine but it depends on type of car so you wont implement in CAR class but it is mandatory for you to implement in child class i.e. SUPERCAR

[Ryan Sykes]

An abstract class cannot be instantiated, and must have at least one unimplemented (i.e. abstract) method. However, it can have other completely implemented methods that are inherited by subclasses. In the case of interfaces, all methods are abstract.

This link has a nice description of abstract classes v/s Interfaces: http://www.codeproject.com/Articles/11155/Abstract-Class-versus-Interface. It should help you understand the role of each and when you would want to use one over the other.

I think you need to clarify your understanding of Inheritance. "Inheritance or Abstract class" doesn't really make sense as Abstract classes are vital parts of class hierarchies, and the subclasses of abstract classes do in fact inherit from their parent abstract class. Perhaps what you are looking for is Concrete v/s Abstract classes.

[Jeff Verdegan]

deepak carter wrote:HI all,

can anyone let me know real time example when to use Inheritence and when to use abstract class??

That question doesn't make much sense. Inheritance and abstract classes go together. It's not an either/or proposition.

Every time you extend a class (whether abstract or concrete), implement an interface, or extend and interface, you're using inheritance. And every time you define an abstract class, to make proper use of it, you have to have a concrete class that inherits from it.

[Winston Gutkowski]

Ryan Sykes wrote:An abstract class cannot be instantiated, and must have at least one unimplemented (i.e. abstract) method.

The second part of that is not true (although more often than not an abstract class will have at least one abstract method); perhaps you're thinking of C++.

@deepak: In answer to your original question:
1. when to use Inheritence - when two classes are inextricably tied together in a parent-child relationship (which is not as often as you might think).

Specifically, the answer to the question "is (child) a (parent)" MUST be true in all cases. For example, if you have two classes: Person and Employee, it's quite likely that Employee should extend (ie, inherit from) Person, because an Employee is a Person.
You should be aware though that there are other ways of implementing this kind of relationship (eg, composition), which are often better than a strict hierarchy.

2. when to use abstract class - when some of a class's behaviour can be properly implemented at a higher level. Subclasses can then use its implemented methods as if they were their own without having to re-implement them.

Another use (the best in my view) is to create "skeleton implementations" for interfaces (you may want to look it up). A classic example of this is the AbstractList class in the Java Collections Framework.

HIH

Winston

[Jeff Verdegan]

Winston Gutkowski wrote:
Specifically, the answer to the question "is (child) a (parent)" MUST be true in all cases. For example, if you have two classes: Person and Employee, it's quite likely that Employee should extend (ie, inherit from) Person, because an Employee is a Person.
You should be aware though that there are other ways of implementing this kind of relationship (eg, composition), which are often better than a strict hierarchy.

Composition is a HAS-A relationship, not IS-A.

public class MyList implements List {
  private final List backing = new ArrayList();

  public boolean add(Object obj) {
    return backing.add(obj);
  }

  public Iterator iterator() {
    return backing.iterator();
  }

  // ... etc. ...
}

MyList IS-A List: true
MyList IS-AN ArrayList: false
MyList HAS-AN ArrayList: true

[Winston Gutkowski]

Jeff Verdegan wrote:Composition is a HAS-A relationship, not IS-A.

Yes, but it can be used to simply extend a class's capabilities, especially when you're not really sure if you want to tie them together or not (or publicize the relationship to clients). I guess what I was trying to say is that inheritance should be used sparingly.

Winston

[Jeff Verdegan]

Winston Gutkowski wrote:

Jeff Verdegan wrote:Composition is a HAS-A relationship, not IS-A.

Yes, but it can be used to simply extend a class's capabilities, especially when you're not really sure if you want to tie them together or not (or publicize the relationship to clients). I guess what I was trying to say is that inheritance should be used sparingly.

Winston

Exactly. Prefer composition over inheritance, as they say.

[Ryan Sykes]

Winston Gutkowski wrote:

Ryan Sykes wrote:An abstract class cannot be instantiated, and must have at least one unimplemented (i.e. abstract) method.

The second part of that is not true (although more often than not an abstract class will have at least one abstract method); perhaps you're thinking of C++.

Thanks for the correction Winston. I was under the mistaken assumption that abstract classes had to have at least one abstract method. I guess if it didn't, it would be equivalent to a non-abstract class with a private constructor?

Jeff Verdegan wrote:

Winston Gutkowski wrote:

Jeff Verdegan wrote:Composition is a HAS-A relationship, not IS-A.

Yes, but it can be used to simply extend a class's capabilities, especially when you're not really sure if you want to tie them together or not (or publicize the relationship to clients). I guess what I was trying to say is that inheritance should be used sparingly.

Winston

Exactly. Prefer composition over inheritance, as they say.

I found this article on Composition v/s Inheritance to be quite helpful in understanding the concept when I was looking this up a week ago: http://www.artima.com/designtechniques/compoinh.html

[deepak carter]

Hi All


Thanks for your response

There was a typo in the question title.It was Interface or Abstract class i mean when we should use interface or when we should abstract class.

I read a previous blog stating that it all depends upon the project or requirement...but there might be scenarios where only interface will be suitable or abstract class will be suitable???



Thanks in advance

[dennis deems]

deepak carter wrote:Hi All


Thanks for your response

There was a typo in the question title.It was Interface or Abstract class i mean when we should use interface or when we should abstract class.

I read a previous blog stating that it all depends upon the project or requirement...but there might be scenarios where only interface will be suitable or abstract class will be suitable???



Thanks in advance

It's a very popular topic for discussion. Here's this site's distillation of the key points: https://coderanch.com/how-to/java/InterfaceVsAbstractClass

[Jeff Verdegan]

deepak carter wrote:It was Interface or Abstract class i mean when we should use interface or when we should abstract class.

Do you know what an interface is for?

Do you know what an abstract class is for?

Do you understand the differences between what in interface and an abstract class can and cannot do?

If you can answer yes to those questions, then you can answer your own question of when to use an interface and when to use an abstract class. And note that there's nothing that says a given situation can only have one or the other. They're often used together.

If you can't answer yes to those questions, which ones are you unsure about?