On 20 June 2016 at 16:48, Dennis E. Hamilton <dennis.hamil...@acm.org> wrote: > > >> -----Original Message----- >> From: sebb [mailto:seb...@gmail.com] >> Sent: Sunday, June 19, 2016 14:04 >> To: Commons Developers List <dev@commons.apache.org>; >> dennis.hamil...@acm.org >> Subject: Re: [CRYPTO] Defining the public API; are its interfaces >> supposed to be implemented or just used? >> >> On 19 June 2016 at 18:57, Dennis E. Hamilton <dennis.hamil...@acm.org> >> wrote: >> > Being keen about API architectures ... >> > >> >> -----Original Message----- >> >> From: Benedikt Ritter [mailto:brit...@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 <seb...@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. > [orcmid] > > In my application of interfaces, interfaces are (effectively) versioned. > Subsequent releases don't alter existing interface declarations. That's the > whole point.
OK, in that case yes, but I did not read your original statement that way. > If there is another interface (even based on the original one) that defines > an additional method, only classes that have the interface-complying methods > deliver the new interface. Ones that have a method of the same name that is > not an implementation for the extended interface do not expose the extended > version of the interface. > > What am I missing? Introducing a new interface is one way to deal with API evolution. However it forces client code to be editted and recompiled in order to get the new API. And if the client code already has a clashing method name, it will still require additional client code changes. Whereas if the interface is never implemented by client code, additional methods cannot cause problems for client code. >> >> 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-unsubscr...@commons.apache.org >> >> > > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > >> >> > >> >> > ------------------------------------------------------------------- >> -- >> >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> >> > For additional commands, e-mail: dev-h...@commons.apache.org >> >> > >> >> > >> > >> > >> > --------------------------------------------------------------------- >> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > For additional commands, e-mail: dev-h...@commons.apache.org >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
