7

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 GatherParameters() and 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.

Improve this question
4
  • Input validation? Asserting preconditions?
    – Ixrec
    Jan 29, 2016 at 16:44
  • 1
    +1 This is a hugely common pattern. I am surprised I can't think of a name for it. If your question isn't about refactoring, maybe you want to switch the tag to [design-patterns] .
    – dcorking
    Jan 29, 2016 at 16:47
  • I dunno.. staging? I don't think there's a specific term for this when applied to distributing logic across functions.
    – Lightness Races in Orbit
    Jan 29, 2016 at 16:52
  • If you're asking about private method names i'd suggest to split them further and call in a sequence (just like you described here). You shuldn't have these kind of separation of methods exposed (public) by same interface (belong to one object). If you need two step execution (prepare+execute) then first one goes into creational object (factory/repository/builder) and second one is the method of the object created.
    – shudder
    Jan 29, 2016 at 23:52

1 Answer 1

Reset to default
3

I think, what you are referring to here is not a specific design pattern, but a more general software development principle called "separation of concerns". If you constrain these concerns into more specific areas like UI logic, service usage and data processing, you are almost in the MVC/MVP world, which could be indeed seen as a pattern.

On the other hand, having interface agnostic designs even emphasizes the separation of concerns principle, because with separated concerns and clearly defined interfaces for them, you will eventually have minimal dependencies and thus highly reusable software. You can easily imagine that if you define separated solutions for small problems chances are higher that other bigger problems contain your small problem in its entirety than if the solution covers multiple different problems at the same time.

Improve this answer
2
  • Absolutely, its the separation of concerns that makes this split appealing. What I'm wondering is what to call it. What should I call these two methods in my code, and, is there's some conventional term (more specific than SoC) for this pattern?
    – user25946
    Jan 29, 2016 at 21:48
  • 1
    @JonofAllTrades Well, I don't think there is a single answer for how the methods should be called. In a way, this is dependent on who will read your code for which purpose. In this case, I'd advise you to keep in mind that patterns always abstract and it might not be a good idea to search for an abstract name, if a more specific one better expresses your intent.
    – McMannus
    Jan 31, 2016 at 19:30

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.