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?