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:03:42 GMT
On 19 June 2016 at 18:57, Dennis E. Hamilton <dennis.hamilton@acm.org> wrote:
> Being keen about API architectures ...
>
>> -----Original Message-----
>> From: Benedikt Ritter [mailto:britter@apache.org]
>> Sent: Sunday, June 19, 2016 07:08
>> To: Commons Developers List <dev@commons.apache.org>
>> Subject: Re: [CRYPTO] Defining the public API; are its interfaces
>> supposed to be implemented or just used?
>>
>> My unterstanding of crypto is that those interfaces are not to be
>> implemented by Clients.
>>
>> sebb <sebbaz@gmail.com> schrieb am So., 19. Juni 2016 um 14:02:
>>
> [ ... ]
>> > 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.
> [orcmid]
>
> It is my understanding that this difficulty is one that Interfaces can be used to overcome.

Sorry, but that's not the case.

If client code defines a method that is not currently in a superclass
or an interface that it implements, there is no problem.

If in a subsequent release, the superclass or interface happens to
define a method with the same parameters and return type as the one in
the client class, the client method will override/implement it.
However since the original client method was defined before the
superclass/interface method was added, it may well serve a completely
different purpose.

And if the client method has the same parameters but a different
return type, the compiler will complain.

Interfaces and super-classes behave identically in this particular respect.

> It also does not compel all implementations being off the same [abstract] base class.

That much is true.

However if all implementations of the interface *are* the instances of
the defined functionality then it's generally better to use
subclassing.
For example Writer is an abstract class, not an interface.

>  - Dennis
>> >
>> > > 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
>

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


Mime
View raw message