>>> "R. Mathur" <[EMAIL PROTECTED]> 10/3/99 10:25:02 AM >>>
>To prevent instantiation occurred to me also but this could have
been
>achieved by making the constructor private. And what is the harm
even if we
>have an object??
But an HttpServlet *is* an abstract object (in design terms - not
just Java implementation terms).
It represents an object which has some Http interface and nothing
more, therefore, because there is no functionality, it must be
abstract.
It is exactly the same design decision which goes to making
java.util.AbstractCollections abstract.
They have some functionality but only in terms of expressing the pure
Collection and doing the spade work needed for a large subset of their
likely subclasses.
It is in fact, good design.
To argue the reverse: why should an HttpServlet be concrete?
What reason is there - if you have a private cons you can't
instantiate it... so why make it concrete?
This is what the abstract applier is for. To help with objects of
this nature.
Nic Ferrier
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
