aspose file tools*
The moose likes Beginning Java and the fly likes Question - Static class vs. interface Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Question - Static class vs. interface" Watch "Question - Static class vs. interface" New topic

Question - Static class vs. interface

lydia westland
Ranch Hand

Joined: Feb 24, 2002
Posts: 72
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.

Lydia<br />~~~~~~~~~~~~<br />I love Italy team.
Madhav Lakkapragada
Ranch Hand

Joined: Jun 03, 2000
Posts: 5040
Can somebody transfer this post to the Java In General - Beginners forum, please.
No, really being honest... :roll:
- satya

Take a Minute, Donate an Hour, Change a Life
Robby Singh

Joined: Mar 16, 2002
Posts: 11

Beware of Scorpio, it has sting in his tail
Peter den Haan
Ranch Hand

Joined: Apr 20, 2000
Posts: 3252
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 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 ]
Cindy Glass
"The Hood"

Joined: Sep 29, 2000
Posts: 8521
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.
I agree. Here's the link:
subject: Question - Static class vs. interface