I'm revisiting old code, and I noticed that the main logic is in one method, which is longer than I'd like (~60 lines). So I split it, and there's a natural seam on which to do so: the first half gathers parameters from UI objects, validates them, confirms a file overwrite if necessary, and logs that the procedure start. The second half is the actual meat: it opens a file, connects to a service, and records data. This works well because the second method is now interface-agnostic, it just accepts parameters.
However, I'm not clear on how to name these two halves. The best I've come up with is
RecordData(). I feel like there should be a common name for this: one method which collects and vets inputs and one method which accepts (and trusts) those parameters and just gets on with the doing.
To be clear, I'm not asking about what this type of refactoring is called ("extraction," I guess), but rather for the resulting code pattern of "Prep/Test" method and "Do" method.
Incidentally, the vague name for
RecordData() applies in this case, because the methods retrieve data from a user-selected table in Salesforce. It's not known at compile time what type of data will be recorded.