commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [CRYPTO] Defining the public API; are its interfaces supposed to be implemented or just used?
Date Sun, 19 Jun 2016 21:05:23 GMT
On 19 June 2016 at 15:08, Benedikt Ritter <britter@apache.org> wrote:
> My unterstanding of crypto is that those interfaces are not to be
> implemented by Clients.

OK, so does that mean that clients cannot provide their own implementations?

> sebb <sebbaz@gmail.com> schrieb am So., 19. Juni 2016 um 14:02:
>
>> On 19 June 2016 at 12:44, Jochen Wiedmann <jochen.wiedmann@gmail.com>
>> wrote:
>> > On Sun, Jun 19, 2016 at 12:49 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> Use-only interfaces are much easier to evolve as methods can be added
>> >> without affecting client code.
>> >
>> > That applies (IMO) only, if there is an abstract base class, and users
>> > are actually deriving from that.
>>
>> By a use-only interface, I mean one that is not implemented by user code.
>> i.e. the code does not derive from the interface, it only uses it to
>> define fields etc.
>>
>> This info is taken from
>>
>> https://wiki.eclipse.org/Evolving_Java-based_APIs#Example_4_-_Adding_an_API_method
>>
>> Users deriving from an abstract base class do not have to change code
>> to implement new methods.
>> But if their class happens to define a method with a name that is
>> subsequently used by the Crypto abstract class, there will be a clash
>> which will require them to recode.
>>
>> > Jochen
>> >
>> >
>> > --
>> > The next time you hear: "Don't reinvent the wheel!"
>> >
>> >
>> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message