On 19 June 2016 at 15:08, Benedikt Ritter <brit...@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 <seb...@gmail.com> schrieb am So., 19. Juni 2016 um 14:02: > >> On 19 June 2016 at 12:44, Jochen Wiedmann <jochen.wiedm...@gmail.com> >> wrote: >> > On Sun, Jun 19, 2016 at 12:49 PM, sebb <seb...@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-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
