Nick Hodges has made “program to the interface, not the implementation” a mantra for good practice. And I completely agree.
My focus continues to be on legacy projects, as most of my work lies in that area. As much as I love Delphi 12 Athens, I spend the majority of my time in Delphi 2007, and am likely to do so for the foreseeable future.
In the context of legacy projects, I recently applied “program to the interface” to a form, a dialog used very widely in a large application. This arose because I needed to replace some components on the dialog, and a progress bar, in particular, had a different interface than the TProgressBar it replaced. Since the dialog is called from dozens of other modules, the changes would ripple all through them.
After considering the issue for a bit, I redesigned to hide the specific details of the new progress bar and expose them generically through properties in the dialog. That led me to write this article, as I had not previously thought much about “program to the interface” at the form level.
It is all too common in legacy projects to find too much code on the forms, when it should instead be in business logic modules or in data modules. And despite best efforts, it is easy to slip into letting such things remain normal.
In this case, however, I elected to reshape the external interface of the dialog, so that the implementation was encapsulated. I still had to revise the code in the calling modules, but it is unlikely that I will go through that again, having now hidden the internals. And simple as it is conceptually, I hope that you may find it worth considering in your own project maintenance.