What is the point of using an abstract class? For example, why would you want to have to, in the child class, redefine all the methods marked as abstract from the parent class?
Also, what is the difference between abstract classes and an object interface?
If anyone can shed any light on this it'd be much much appreciated!
Thanks
darktoast
Using class abstraction
Moderator: General Moderators
Re: Using class abstraction
Abstract classes allow you to start the class for which the other classes that extend it would only need to implement the abstract methods.
The Interface defines a clear set of methods that each class that implements it needs to have.
Also a class can implement as many interfaces as it needs, but can only extend one class be it abstract or a regular class that isn't final.
The Interface defines a clear set of methods that each class that implements it needs to have.
Also a class can implement as many interfaces as it needs, but can only extend one class be it abstract or a regular class that isn't final.
Re: Using class abstraction
Apart from behaviour (the methods in the interface) abstract classes can implement some methods already...idarktoast wrote:What is the difference between abstract classes and an object interface?
Apart from the requirement to implement all abstract functions you can also take advantage of the already implemented functions in the abstract class.idarktoast wrote:What is the point of using an abstract class? For example, why would you want to have to, in the child class, redefine all the methods marked as abstract from the parent class?
Lets say you have an object of type Tree (as in forest Tree, not the programming term
). This object is an abstract class, because there is no "Tree", there are evergreens, maple trees, etc. However, you can still go outside and point and say "This is a tree", because that is what it truely is. Lets say you dont know what kind of Tree you will be using, but you know it will be a Tree, you can use Polymorphism to then access specific methods about that tree that will get its special information
I always like real life programming examples when talking about object-oriented programming.
Abstract Class. This concept allows you define some type of object in a generic fashion while leaving the not-so-generic implementations to a concrete sub-class.
Lets say you have a payment object for an auction system. There are several different types of payments you can accept (CC, Check, EFT). All these payment types have certain things that are common to them all (payee, payment date, amount, payment id). They also have things that are not common to each other (payment type, credit card number, bank routing number, check number).
You can have an abstract class the define and implement the common factors about payments then sub-class that abstract object for each type of payment and it's individual implementations. This allows you to abide by the DRY method of programming (no duplicate code) and it also allows you to pass any payment (regardless of it's sub-class type) around a system generically. Lets say your auction system needs to verify a payment has been made. Well you can pass the payment around in its abstract form and check that a payment date has been set and the payment amount is correct. You don't have to know what kind of payment it is to act on those methods. This allows your whole system to be more generic and thus more re-usable.
Interfaces. Interfaces allow you to define a "Contract" that objects must abide by. This contract specifies that certain methods must be implemented and must return predefined result types. Any class that implements an interface says that it is abiding by that contract and can be expected to act like the interface demands it act.
Lets look at Java as an example for this. Java defines a serializable interface. This interface says that any object that claims to implement the serializable interface must be able to break itself down into a serialized string for storage when asked to. It must also be able a to rebuild itself into it's previous state using the serialized string it produced earlier.
Now if I need to break an object in Java down into a serialized object for storage and then be able to rebuild that object later form it's serialized form, I can look at the API for the object I'm using and see if it implements the serializable interface. If it does, I can depend on that object to act the way it's supposed to.
Hope that helps a little.
- Eric
Abstract Class. This concept allows you define some type of object in a generic fashion while leaving the not-so-generic implementations to a concrete sub-class.
Lets say you have a payment object for an auction system. There are several different types of payments you can accept (CC, Check, EFT). All these payment types have certain things that are common to them all (payee, payment date, amount, payment id). They also have things that are not common to each other (payment type, credit card number, bank routing number, check number).
You can have an abstract class the define and implement the common factors about payments then sub-class that abstract object for each type of payment and it's individual implementations. This allows you to abide by the DRY method of programming (no duplicate code) and it also allows you to pass any payment (regardless of it's sub-class type) around a system generically. Lets say your auction system needs to verify a payment has been made. Well you can pass the payment around in its abstract form and check that a payment date has been set and the payment amount is correct. You don't have to know what kind of payment it is to act on those methods. This allows your whole system to be more generic and thus more re-usable.
Interfaces. Interfaces allow you to define a "Contract" that objects must abide by. This contract specifies that certain methods must be implemented and must return predefined result types. Any class that implements an interface says that it is abiding by that contract and can be expected to act like the interface demands it act.
Lets look at Java as an example for this. Java defines a serializable interface. This interface says that any object that claims to implement the serializable interface must be able to break itself down into a serialized string for storage when asked to. It must also be able a to rebuild itself into it's previous state using the serialized string it produced earlier.
Now if I need to break an object in Java down into a serialized object for storage and then be able to rebuild that object later form it's serialized form, I can look at the API for the object I'm using and see if it implements the serializable interface. If it does, I can depend on that object to act the way it's supposed to.
Hope that helps a little.
- Eric
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Re: Using class abstraction
An abstract class provides two great benefits:idarktoast wrote:What is the point of using an abstract class? For example, why would you want to have to, in the child class, redefine all the methods marked as abstract from the parent class?
- It requires the extending class to conform to an interface guaranteeing compatablity
- It allows the programmer the freedom to implement some or all of the methods of the class to solve a particular problem
This combination of interface compatablity plus implemention freedom ends up being very useful, especially when writing code to work with a framework or library. The framework/library builder can create an abstract class that provides interoperablity with their code, while at the same time allowing you do build a custom solution.
(#10850)
-
idarktoast
- Forum Newbie
- Posts: 2
- Joined: Mon May 01, 2006 1:33 pm
Thanks
Thanks for all the replies - everyone was a big help 
darktoast
darktoast