This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
Very similar to the thread you posted yesterday. Did you not understand the answers to that?
An abstract class represents a type of object, as I said yesterday, a Bus is a Vehicle. A Dog is an Animal.
Now there might be specialised behaviour which certain objects are expected to display. For example a Vehicle may be Taxable. A Frame in a display may be Serializable (in fact, I think, most Swing components are).
You use an abstract class to represent a type of object, which can have abstract or concrete methods or both (or neither). Interfaces have only abstract or empty methods You use an interface to represent a type of behaviour. So the Taxable interface might have this sort of structure:-
Now, your interfaces have only empty methods. But when you have your Bus class, you have to implement the payTax methodMost taxable vehicles will have a different implementation of that method.
Not like a concrete method in the abstract Vehicle or MotorVehicle classes. If you have a concrete method you expect it to be the same (at least in most cases). If you have an abstract method in your abstract class, you expect it to be different in most methods.
You will find more details on the link I gave you yesterday, and also here.
Most of the time it's good to use the most abstract thing you can. What does that mean? Say I'm writing a method called doSomething() ...
By using an interface I make my method more flexible for future users. The folks at Sun created a List interface just so I could do this.
An interface is more abstract than an abstract class, so I'd prefer to use an interface when I can.
When would an interface not do the job? Maybe I'd like to provide some default behavior for others to use so I make an abstract class. They can override methods or use the ones I provide. Maybe I'd like to force users to override certain methods. I can make them abstract, too.
You see this a lot in frameworks. Maybe I have an abstract class that can do most of the steps of some task, but not all of them. My project has an abstract database accessor with methods like connect(), getSQL(), executeQuery() and formatResults(). The connect() method is complete and ready to use. The execute() and format() methods are, too. But the getSQL() method doesn't know what SQL you might want to use. That method is abstract, forcing us to implement it and return a SQL string. We can also customize format() if we really want to, but we don't have to.
Does that help?
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi