1

I am implementing a system where in the front-end, the user needs to select if option A or option B should be active. Depending on the option, a conversion module converts other input data for use with a low-level calculation-core.

If option A is active, operations [a, b] need to be performed by the conversion module. Correspondingly, if B is active, operations [c, d] should be carried out.

I now have two options for how to design this.

First option:

# front-end code
let calculate <- (data, A_active, B_active) =>
  let converted_data <- conversion_module.convert(data, A_active, B_active)
  return calculation_core.calculate(converted_data)

# conversion_module
export convert <- (data, A_active, B_active) =>
  let out_data <- clone(data)
  
  # the following decides which operations to perform
  if A_active: 
    out_data <- a(out_data)
    out_data <- b(out_data)
  if B_active:
    out_data <- c(out_data)
    out_data <- d(out_data)
  return out_data

The advantage with the first option would be that I don't need to know in the front-end which operations need to be performed to achieve A and B, which seems to fulfil the facade design pattern.

Second option:

# front-end code
let calculate <- (data, A_active, B_active) =>
  # the following decides which operations to perform
  let do_a, do_b <- A_active
  let do_c, do_d <- B_active
  let converted_data <- conversion_module.convert(data, do_a, do_b, do_c, do_d)
  return calculation_core.calculate(converted_data)

# conversion_module
export convert <- (data, do_a, do_b, do_c, do_d) =>
  let out_data <- clone(data)
  if do_a:
    out_data <- a(out_data)
  if do_b:
    out_data <- b(out_data)
  if do_c:
    out_data <- c(out_data)
  if do_d:
    out_data <- d(out_data)
  return out_data

The advantage here is modularity - if I wish to use the conversion module elsewhere, I am not confined to only cases where A and B are relevant. However, this also means the front-end needs to be aware of the operations performed by the conversion module.

How can these design patterns be described? Which options leads to the most robust code?

3

There is no such thing as more robust code in general.

Some implementations can be improved by closely following various patterns, but for others it will lead to over-engineering. So you should choose the solution that fits your use-case.

Is it likely that you'll need to reuse conversion module? Then it could be worth going with the second option.

Is it likely that you'll have multiple points in your app that need to do this kind of conversion? Then, perhaps it is better to go with the first.

Both scenarios are likely? Add another layer of abstraction in-between these two and have it act as a facade, while keeping your conversion module fairly reusable.

Neither are likely to occur? Don't bother with patterns, it's a waste of your time and it'll make it more difficult to understand what is actually going on, when all of the relevant code is split between three different places.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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