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
    I miss any effort of yours in this question to solve this by yourself. What did you already think of, and why doesn't it satisfy your needs? Recommended: meta.programmers.stackexchange.com/questions/6473/…
    – Doc Brown
    Mar 15, 2014 at 22:27
  • 1
    I suggest editing to focus on the situation you are in rather than trying to create a hypothetical out of it.
    – Móż
    Mar 16, 2014 at 1:37
  • @Ӎσᶎ I am specifically looking for either a formal definition of the pattern/anti-pattern structure, or general rules of thumb based on professional experience. If that's unclear, i welcome edits to the question :) (and if that's not appropriate to this site, then i welcome recommendations for other stack exchange sites to use, or to not use any at all) Mar 16, 2014 at 2:22
  • What alternative do you have in mind when talking of an "anti-pattern"? I mean, I guess the code inside of DoSomething has to be placed somewhere, and it does not seem to belong in any of the four classes it makes use of. So it needs a new place, and a new fifth class is the only obvious solution. Or isn't the placing of the code what you want to discuss, is there something different about the design what bothers you?
    – Doc Brown
    Mar 17, 2014 at 18:31

3 Answers 3


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.

  • Or even better, it's Composition.
    – Casey
    Mar 16, 2014 at 3:38
  • @Telastyn is that what normally is meant by orchestration then? just a fancy name for abstraction? i'd love a reference - debunking the idea that this is a pattern/anti-pattern would be extremely useful. Mar 16, 2014 at 4:06

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.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.