Jason, I actually started servlet programming with your de facto book. :-) Thanks a lot.
It would make more sense if we divide the case into API designer and API user. For API design, interface has more advantages over classes. For specifications like servlet API, DOM, interfaces make perfect sense that I can use the interface and don't care about the implementation. If my servlet runs on Tomcat, it should have no problem to run on WebLogic. If I subclass from an API class, I'm tied to the implementation details of the base class for ever, which might change from release to release. If you inherit MultipartRequest from HttpServletRequest class(suppose there's one), it's also not guaranteed to work in a new servlet version: 1) The new version might add more functionalities that you can automatically inherit from. But these methods might add new semantics of the implementation so that calling these new methods will corrupt the state of you subclass. 2) If your are bad luck that the new methods happen to have the same signatures with your subclass's custom methods. If the return type is different, your class won't compile. If the return type is the same, you are practically overriding the new methods of the base class, which is not your original intent and will also break your code. Inheritance breaks encapsulation. One example is JDK's Properties class, which inherits Hashtable. While Properties intends to take String as key, but nothing can stop a careless programmer to use its super class, Hashtable's methods to add an entry with Object as key. This will corrupt the inner state of subclass, Properties, therefore it will break if you intend to take it as String. It makes perfect sense that you wrote another MultipartRequest instead of implementing HttpServletRequest interface. By implementing an API interface, you are making the commitment to be part of the API, which you are obligated to support if the interface evolves. For a specification like DOM, interface is better than class that multiple implementations can compete for the performance while all support the application built on top of the interfaces. For a special need like custom Element, I probably would do away with composition instead of inheriting from a base class. --Li -----Original Message----- From: Jason Hunter [mailto:[EMAIL PROTECTED] Sent: Wednesday, August 01, 2001 6:34 PM To: [EMAIL PROTECTED] Subject: Re: renaming elements Li Liang wrote: > > But inheritance has fundamental limitations. > Once you subclass a API class, you are tied to that class for ever. Any > new changes made to the base class may break your code. While with > interface, you can completely replace with a new implementation, but all > existing code working with the interface will be guaranteed to stay > working, enjoying whatever benefit the new implementation brings. This > is especially important for API classes. One could argue just the opposite. In servlets I have a MultipartRequest class that simulates the HttpServletRequest interface but doesn't implement the interface. Why not? Because I each servlet API release they add new methods to the HttpServletRequest interface. If I made my class truly implement the interface, it would stop working on every new servlet release (doesn't implement X, must be declared abstract), causing me no end of tech support issues. If HttpServletRequest were a class, on the other hand, then I could subclass it, implement my functionality, and let the other methods be inherited *even for new API versions*. Things would be "guaranteed to stay working, enjoying whatever benefit the new implementation brings." :-) As applied to DOM, having Element as an interface makes it very hard to write a specialized subclass of Element. -jh- --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
