This week's book giveaway is in the OCPJP forum. We're giving away four copies of OCA/OCP Java SE 7 Programmer I & II Study Guide and have Kathy Sierra & Bert Bates on-line! See this thread for details.
Howdy, there are thousands of books about java out there, choose one and look it up. My favorite is Thinking in Java, wich comes for free. If you have concrete questions, feel free to ask them. cu, Tobias
Both are fairly simmilar in behaviour - both provide a template for an object type. i.e. provide method signatures required by classes extending or implementing them. Check the listed thread above for other similarities/differences. The basic behaviour of abstract classes and interfaces is different though - interfaces can do nothing beyond defining method signature or defining final constants, whereas abstract classes can include some actual method functionality (you only need one method in an class to be abstract for the whole class to become abstract). There is one very important difference between interfaces and abstract classes, and it is the one you should consider most carefully when choosing which to use: that is the ability to upcast to more than one base type. If a class is a sub class of an abstract class, it is of the type of that abstract class, and no other. However, a class can implement as many interfaces as it likes, so there is not the same limit where interfaces are concerned. This is particularaly important in two types of application: the very large, and the distributed. Consider this (somewhat exagerated) example: you have an abstact Authentication class with a login(String username, String password) method. These Authentication classes are user in an Authenticator package which handles your application's security. You develop with this for many months, so eventually you have hundreds of subclasses of Authentication, all implementing the login method, each for the different sub-systems of your application. Then you someone notices you need to change part of the application to use a username, password and an authentication token. What you'd have to do is something like implement a method on each of the Authentication sub-classes to handle this, and so break the Authenticator package, since there is now more going on than you abstract class defines. However, if your login methods were defined in an interface it would be easy enough to either extend the interface or (even better) create another interface and you'd only have to add code to the authenticator package, not change existing code. [ April 23, 2004: Message edited by: Paul Sturrock ]