0

(this question is written from a functional javascript point of view)

say you have some pure functions:

function a (arg) {
  ...
  return result
}

function b (arg) {
  ...
  return result
}

function c (arg) {
  ...
  return result
}

And in your business logic, you are looping through a list of data and processing each datum

for (const datum of data) {
  const { preA, preB, preC } = datum

  const postA = a(preA)
  const postB = b(preB)
  const postC = c(preC)
  ...
}

Say that it's not just three function calls in this for loop, but dozens, and you want to encapsulate this set of functions into some outer function:

function outerFunction(datum) {
  const { preA, preB, preC } = datum

  const postA = a(preA)
  const postB = b(preB)
  const postC = c(preC)
  ...

  return {
    postA,
    postB,
    postC,
    ...
  }
}

And your business logic now looks like:

for (const datum of data) {
  const { postA, postB, postC, ... } = outerFunction(datum)
  ... 
}

How would you describe this outer function? facade function? wrapper function? helper function? orchestrator function?

Would you call it something else? Would you approach this code in a different way?

12
  • 2
    It doesn't really change the question, but a pure functional style would use a map function rather than iteration. Commented May 31, 2024 at 15:07
  • 2
    I would try to avoid naming functions like this based on their structure and try to name them based on the actual real-world functionality/behaviour they represent, using terminology from your real-world business/problem domain as far as possible. It can often be very hard for people to understand code where names are based on "what it is". (A good reason to avoid such names -- e.g. if you are thinking of naming something a "handler" or "wrapper" or "manager" or "orchestrator" then it generally won't help future developers as it doesn't tell them anything useful) Commented May 31, 2024 at 15:13
  • 2
    In a functional style, it'd be data.map(outerFunction).reduce(somethingElse) (or something more specific than reduce) Commented May 31, 2024 at 16:05
  • 3
    I would call it a function (like everything else in FP). Commented May 31, 2024 at 18:03
  • 2
    Doc Brown has a point there. On the one hand, yes, this is a kind of a wrapper function, but really, all you do when writing a program is you're calling functions inside other functions, and composing functions (and calling the composition inside other functions) - you distribute the responsibilities across various levels and you give each function an appropriate, descriptive name. You're not doing something particularly unusual. It's fine to discuss what kind of function it is, but I'd be more concerned about giving it a descriptive name that makes business logic read better. Commented May 31, 2024 at 23:24

1 Answer 1

2

I would call it Bob. Assuming Bob made sense in your domain.

As for how to describe this implementation, I wouldn’t mind seeing it described as an Aggregating Function.

I hesitate to describe it as an orchestrator only because it’s just retrieving values. But technically it is an orchestrator as well. Just a boring one.

Always remember, name things after why you would call them. Not what they do. What they do is none of the callers business.

1
  • Have to disagree. "Fred" is much more descriptive. Commented Jun 2, 2024 at 1:38

Your Answer

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.