Win a copy of Learn Spring Security (video course) this week in the Spring forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Abstract Methods and Classes

 
Martin Vladimiruk
Greenhorn
Posts: 1
Chrome Java Windows Vista
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What are abstract methods and classes for? I can not see any necessity to use this. Can anyone give me any example of use? When is it necessary?
 
Manu Somasekhar
Ranch Hand
Posts: 44
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you want to have a common signature to your methods (like methods within an interface) and some common behaviors (like methods defined in a super class in an inheritance hierarchy), you can go for an abstract class.

Google is your friend. Some of the best examples are here
 
Winston Gutkowski
Bartender
Pie
Posts: 10086
55
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Martin Vladimiruk wrote:What are abstract methods and classes for? ... Can anyone give me any example of use?

Yes: AbstractList - In fact all of the 'Abstract...' classes in the Java Collections API.

When is it necessary?

When you have a class (or interface) based hierarchy that you can provide a partial implementation for.

I can not see any necessity to use this.

Maybe not, but some very clever people were involved with creating Java, so you might want to ask yourself why they spent the time to add it. It's also possible that you simply haven't yet encountered a situation where you need it.

Winston
 
Steve Luke
Bartender
Posts: 4181
21
IntelliJ IDE Java Python
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Martin Vladimiruk wrote:When is it necessary?
I would hazard a guess to say that it is not really necessary to have Abstract methods and classes when you have interfaces, but I know it is extremely convenient and useful to have them.

Winston's example of the AbstractList is a perfect example. The List interface defines all the common method signatures for any list implementation, so AbstractList is not necessary. But since much of what a list does will be the same, regardless of how the list is implemented, you can extract many methods out into a common parent - the AbstractList - so you don't have to have each List implementing class re-implement the same work for what contains() or toString() does (as examples). That means less code, and less code usually means fewer bugs. There are other ways to achieve it, but in this case an abstract parent class makes sense; it is the easiest to implement, easiest to use, doesn't interfere with a clean class-hierarchy.

Finally, since it is abstract it does not have to provide implementations for every method in the List interface; that is good because now you aren't forcing one implementation on child-classes and are forcing child-classes to actually implement the bits that are not common.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic