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]
