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