Say that you’re doing a code review, and you find yourself faced with an orchestration pattern:
class OrchestrationClass {
private Configuration _configuration;
private DataStore1 _dataStore1;
private EfficientComputationService _service;
private ResultPrettifier _formatter;
public DoSomething () {
with (data = _dataStore1.LoadForConfiguration(_configuration)) {
return _formatter.PrettyPrint(_service.Process(data));
}
}
}
Under which circumstances is this considered to be a valid pattern/anti-pattern (and how is the anti-pattern to be cleanedup/refactored)?
For context:
This recently came up in a code review, and several people mentioned the pattern/anti-pattern. Searches of the standard patterns literature, related Google search and scan through blog posts / wikis have all led to indirect mentions. Which leads me to believe that this pattern / anti-pattern hasn’t yet had a formal treatment (or, if it has, it’s not yet online). Hence – the question is here, where someone more experienced or widely read might be able to answer (or provide a reference)
4
If by orchestration you mean take 2+ parts and use them to do 1 larger task… this is called programming where I live. Maybe “abstraction” if you’re feeling frisky.
I mean seriously, this is basic object oriented programming. It isn’t special, and doesn’t need a fancy name.
2
I usually talk about Orchestration in the context of RESTful services. That is, we provide RESTful services that give direct access to various resources. But there are some teams out there that, for one reason or another, just aren’t in a position to handle that. So we provide an orchestration layer on top, where we tie together the resource calls that we’d expect them to do.
(That idea is a little controversial, because as expected, when I’ve been on a team that did that, due to politics the orchestration layer just devoured and hid the REST layer completely.)
Except as a general idea, I haven’t heard orchestration as such doesn’t come up in application design, though. In a sense it’s a consequence of modular, shallow-call-stack design. At some point you have to pull the low-level pieces together.
To me that’s a question of whether you throw in a layer of abstraction between the main() or API layer and the logic layer. Do the orchestration at the very top? (i.e. in your main() method, or in the webapp handler classes) Or if you throw in a layer of abstraction between main() and the workers?
I usually do, because I like to pretend that the application logic is decoupled from the API implementation. But I don’t know if there’s a formal name for that, or rules around it.
Your code just looks like an example of the “Single Level of Abstraction” concept (note that I intentionally don’t use the word “pattern” here), which is a good practice under normal circumstances. The idea of this concept is to have same level of abstraction for all statements inside a method.