Tidying: New Interface, Old Implementation
[I'm likely to delete this tidying because it is rarer & less clear. If you find it helpful, lmk & I'll leave it in. I’m sending it out to all subscribers because I need an example.]
So you need to call a routine & the interface makes it difficult/complicated/confusing/tedious. Implement the interface you wish you could call & call it. Implement the new interface by simply calling the old one (you can inline the implementation later after migrating all other callers).
Creating a pass-through interface is the micro-scale essence of software design. I want to make some behavior change. If the design was like thus and so, making that change would be easy(-er). So make the design like that.
The same impulse is true whether we are:
Coding backwards--start with the last line of a routine as if you already had all the intermediate results you needed.
Coding test-first--start with the test that needs to pass.
Designing helpers--if only I had a routine, object, service that did XXX then the rest of this would be easy.
[really really needs an example]
Interacting with 3rd party vendor APIs comes to mind for this pattern. You have no ability to change their API, it is immutable. It doesn't match up with what you're actually trying to achieve with your business logic. Write the interface to that API from the business logic *that makes the most sense for the business logic*. And within that sectioned-off layer/library/module, you can deal with the messiness of translating the data into the shape the API demands.
Leaky abstractions are good candidates. At some point we need to stop the leakage of internal implementation to the caller and this is a good way of arresting that. Another, perhaps related, is an API at the wrong level of abstraction. Some message queue API's come to mind that reveal the mechanics of the message broker and not the semantics of messages and queue.
This gets my vote for being included in the final copy because the application may be rare but the problem is fairly common.