Change request of a behaviour implemented deep in the call stack but is configured in the first calls

by Jp_   Last Updated September 14, 2018 17:05 PM

Problem: I have a complex system with many layers of abstractions. I need a different behaviour low in the abstractions, but to be configured high in the abstraction.

Solution 1: Having a parameter to define the chosen behaviour and pass this parameter down in the abstraction until the method that uses it.

Solution 2: Have a configuration module set high in the abstraction and the module low in the abstraction have access the configuration module.

Solution 3: Strategy Design Pattern?

According to the Clean Code book the solution 1 is bad because a function shouldn't have control flags as parameters, the different path should become a new function. Doing so in this case would duplicate what else is called in this function and in the underlying ones.

The problem with the solution 2 is the scope of the configuration, if it's too high it becomes hard to test the code as I have a dependency that I can not inject, if I inject I'm kind of in the solution 1. Also following an Hexagonal Architecture I could be forcing my Application layer to depend on external modules, for example if the user access the different code paths depending from which page he accessed the functionality.

A friend recommended me to take a look in the Strategy pattern, but for what I remember it needs to pass a reference to the implementation that's going to be used and in the end is similar to injecting the dependency.

My conclusion

I feel that the solution 2 is better as I can define in which level of the abstraction I will have this configuration module, but I would like to know if the problem is solved for a better design pattern or refactoring strategy.



Related Questions





How do I prevent unknowningly duplicating code?

Updated December 14, 2017 06:05 AM