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.
Hi ranchers, When I read the JSP and Servlet specs, I found some are abstract classes, while others are interface. what's the main difference between these two, besides one is using key extends and the other is using implements? Why do the specifications particularly use abstract classes in one place, and use interface in other places? I think hard about this question but haven't reach a convincible answere. can anyone help me out? thank you so much.
Agreed, Satya. Given that anyone studying for the SCWCD developer can be assumed to be a SCJP, this does not appear to be the best forum for this question. Hold steady while we beam you over... Very funny, Scotty. Now beam their clothes too please - Peter PS. The specification uses interfaces almost everywhere for the same reasons that they are a good idea elsewhere: so that you can have wildly different implementations that do the same (conceptual) job in completely different ways. After all, different servlet containers can differ substantially in environment, requirements and architecture. The few classes in javax.servlet... all have specific reasons to be a class and not an interface: GenericServlet and HttpServlet are convenience classes (implementing the Servlet interface) to save you coding. The Servlet*Stream classes need to be (abstract) classes if only because the java.io streams are classes. Cookie is a class because it's a very self-contained entity with no real need for different implementations. Et cetera. [ March 17, 2002: Message edited by: Peter den Haan ]
Actually this is a very good question. - If you choose to use an abstract class, then in order to use it you MUST sub-class it. That automatically means that you can not subclass anything else. That can be a problem. Even if it works for now, sometime down the line - when you are refactoring things - all hell can break loose. - If you create an abstract class and try to implement it in existing code - retrofitting is often a nightmare. In real life the majority of coding is NOT brand new stuff. It is enhancements, refactorings, and bug fixes (unless you are Sun and get to write the "base" classes). - Abstract classes create a heirarchtical structure that is rigid. Interfaces allow for much more flexible structures. For good reference material try "Effective Java" by Joshua Bloch Item 16: "Prefer interfaces to abstract classes" starting on p 84 On the other hand, if there are REALLY lots of methods that can be inherited without overriding them, then it does make sense to centralize that code in an abstract class. p 88:
. . an interface is generally the best way to define a type that permits multiple implementations. An exception to this rule is the case where ease of evolution is deemed more important than flexibility and power. Under these circumstances, you should use an abstract class to define the type, but only if you understand and can accept the limitations.
Dr. Josh actually recommends using a "skeletal abstract Implementation" (by convention named AbstractInterface). Essentially you make a class that implements the Interface and then provide actuall implementations for those methods that should be left abstract because they would vary from implementation to imlementation. You should provide the actual implementations for the other methods in th class. You can see these in Sun's code alot in the Collections classes - AbstractCollection, AbstractSet, AbstractList etc. Dr Josh p86:
The beauty of skeletal implementations is that they provide the implementation assistance of abstract classes without imposing the severe constraints that abstract classes impose when they serve as type definitions.