In general, should we apply a policy that if you need to extend a class
which is not API, then you must expose any of the API you expect to support via
an interface? So your API class which extends a non-API class would be required
to define an interface, and then expose that interface as API.
We will hit issues with this approach for static factory methods, so we may
need another approach for that -- or require that any method that is a static
use a singleton class which could then create or manage objects as the static
method would have. There are advantages to an approach like this where we can
better control and coordinate the program flow through the otherwise static
methods in order to address possible issues of concurrency and
thread-safeness.
What's the motivation behind wanting to expose an API class from an
extension to an internal class? What are the benefits to that approach?
-------------------------------------------------------------------------
Kind Regards,
Michael D. Elder
Rational Studio / J2EE Tools
Development
IBM RTP Lab
Ext: (919) 543-8356
T/L: 441-8356
mdelder@xxxxxxxxxx
Wednesday, May 11, 2005 11:09 AM
To: wtp-dev@xxxxxxxxxxx
cc: Jim
des Rivieres <Jim_des_Rivieres@xxxxxxxxxx>
From: Arthur Ryman
<ryman@xxxxxxxxxx>
Subject: [wtp-dev] API Types that Inherit from
Non-API Types
