Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [wtp-dev] API Types that Inherit from Non-API Types

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     
Ext: (919) 543-8356
T/L: 441-8356
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

The API scanning reports now flag refrerences to non-API types as errors. Clearly, an API method must not have non-API types as arguments, return value or exceptions. However, inheriting from non-API types need further examination.

In general, an API class should hide its implementation, so only inherit from non-API types when necessary. If you do so, then the API must assume ownership of all inherited public and protected methods since these are visible to clients. The API class must shield clients from changes to the non-API class. For example, if the non-API class removes a public or protected method, then the API class must add it to avoid breaking clients.

The PMC discussed this topic on Tuesday and arrived at the above policy. If you have other thoughts, please express them now.

By cc, I am asking Jeem to give us the official Eclipse position on this topic, or to help us formulate a position if none currently exists.

Arthur Ryman,
Rational Desktop Tools Development

phone: +1-905-413-3077, TL 969-3077
assistant: +1-905-413-2411, TL 969-2411
fax: +1-905-413-4920, TL 969-4920
mobile: +1-416-939-5063, text: 4169395063@xxxxxxx

Back to the top