This approach seemed to make a lot of sense for this case, too, so I sat down to play it out. If you are interested in a more detailed description of these steps, you can read my earlier post. Given the client used her time wisely and made the necessary changes, releasing the new version will not cause compile errors.
: In a new version, the library removes residues of the old outline. : Then the client has time to move from the old to the new outline.Īgain, the default methods ensure that adapted external implementations and calls are valid and the changes are possible without compile errors. : A new version of the library is released where the interface definition is transitional and combines the old as well as the new, desired outline.ĭefault methods ensure that all external implementations and calls are still valid and no compile errors arise on an update. Using default methods to add, replace or remove single methods of an interface is pretty straight forward and usually consists of three steps (in some cases less): It was essentially the same approach I used for methods. When announcing this post, I had a specific idea of how this was going to work.
#Interface detours how to#
So what we really need is a general step-by-step approach of how to move implementations, callers and declarations from one interface to another. The only way I see to even have a chance of achieving this is to define a transitional phase where both the old and the new version of the interface coexist. I just wanted to look how far I can get.) I'm largely ignoring whether that's a good idea in the first place. (Note that this is the principal requirement for all that follows. until the next release) without any compile errors.
#Interface detours code#
You're a really nice guy/gal, though, so instead of requiring a flag day you would like to give them the opportunity to change their code gradually over time (e.g. If their code is highly coupled to yours, they might have to do this in a separate branch to spend some time on it but that's life, right? You could just do it, release a new version with the changes and tell your clients to fix their resulting compile errors. (But both interfaces are still equivalent in the sense that adapters can be provided to get from one version to the other.) Now you want to substantially change the interface: rename it, move it or revamp it in a way that can not be expressed with changes to individual methods. (Great incentive, eh?) ▚The Problem StatementĪssume, your code base contains an interface which your clients use in all imaginable ways: they have their own implementations, call your code with instances of it and your code returns such instances and of course they use it as types for arguments and return values. Well, read on then, but the rest of the post is really only a description of how I ended up at a roadblock so don't expect too much of it. Well, you're reading this post now and the unfortunate summary is: I foolishly announced that "a future post will look into ways to replace whole interfaces" - also without breaking client code. The first part of this mini-series explained how default implementations allow to add, replace and remove methods without breaking client code.
#Interface detours update#
If backwards compatibility is sacrosanct, this is limited to adding new methods to interfaces (which is their exclusive use in the JDK).īut if clients are expected to update their code, default methods can be used to gradually evolve interfaces without causing compile errors, thus giving clients time to update their code to a new version of the interface.
Default methods were introduced to enable interface evolution.
0 kommentar(er)
