How to refactor a lot of Functions that can be run in two different modes

If the value of run_type can be determined before these are called then classes may be a good solution.

Currently it looks like you call the code this way:

read_text( clean_path( path_join(path, run_type), run_type ), run_type, container ) 

When it could be:

run_type.read_text(path, container) 

This would use polymorphism to call different read_text methods based on the type of run_type.

You may be reluctant to “create a lot of small classes” (in this case it'd be two, for now) but that is typical of OOP. It's a very different style. Rather then pull details towards you and try to know everything, you push details behind abstractions so you can forget about them.

Of course OOP, classes, and the strategy patern are hardly the only way to solve this problem. This question reminds me of the Boolean argument code smell. You can find example solutions for that here and here.

I like to look at how usable the abstraction is from the perspective of the consuming client first, and only second from the perspective of its internal implementation.

If you already have a sizeable code base, what I would do is to look at the code that is consuming this (set of) abstraction(s).

Do calling consumers pass constants or variables for that parameter?

• At one extreme, if users of these methods always pass constants, then those are really two different methods that should simply have two different names, and the parameter should be removed from both.

• At the other extreme, if users never pass constants, always a variable, then it makes sense to keep a single signature with a differentiating parameter.

Of course, we can do both, if there are significant uses of constants being passed as well as uses of the variable, where one implementation (e.g. taking the variable or separate methods) can be written in terms of the other(s), and vice versa, without necessarily affecting the consuming clients.

Please ignore the kneejerk reaction of creating a new class whenever you find a pattern. No one thing can solve all problems.

Creating a new class is a solution, a solution to a type of problems. Its not a solution to all types of problems. The type of problem it solves is when your data has a pattern - a commonality, a repetition of sorts.

The problem you are solving is not based on that pattern. The problem you are facing is a cross-cutting concern. Its a commonality in code. Code and data are two different things.

Object Oriented Programming is great for adding same functionality to similar objects. That is, apply same functions to same pattern of data.

Functional Programming is opposite of Object Oriented Programming. Its great for applying functions that have a pattern, to same data.

You can use OOP to teach singing to sparrows, magpies and cuckows. You can use FP to teach different types of singing to sparrows.

As data can have patterns, functions can have patterns too.

You can only refactor a pattern and nothing else.

When data has pattern you make class hierarchies using inheritance, or make class maps as you would link tables in Relational Database using composition. Both of these are based on commonalities in data.

When code has pattern you use Higher Order Functions.

The code you want to refactor has this pattern: This function divides the flow in two parts, that function over there also divides the flow in two parts, that function further away also divides the flow in two parts. Thats the pattern. Ofcourse being in real world the functions also do something before or after the division. Real world problems arent textbook examples.

There is no language construct in imperative programming to refactor this out. Your only choice is using a functional programming construct: higher order function.

You have to make a higher order function that takes into arguments four functions. In its body the higher order function will first call the first argument function - its the part your unfactored functions have before the if-else statements. Then the higher order function will have the if-else statements i.e. the conditions - this is the fixed part in the unfactored functions, the conditions are always same.

Inside the if statement the higher order function will call the second argument function, and inside the else statement the third argument function.

Finally, after the if-else statements the higher order function will call the fourth argument function.

this looks like you need to configure the calls before you use the functions. This is done by "dependency injection" in OOP or callbacks/"higher order functions" in FP. What you do is you abstract away what is inside of the if blocks and then construct the function and return it. I am not super familiar how you would solve this in python (in JS world you have module.exports/export that make this easier).

def _path_join_local(path_elements): return os.path.join(*path_elements).replace("/", os.path.sep) def _path_join_blob(path_elements): return _clean_path('/'.join(path_elements)) def _get_separator_local(): get_os_path_sep() def _get_separator_blob(): constants.BLOB_PATH_SEP def _get_separator(system_separator): return system_separator * 2 if system_separator == constants.WINDOWS_PATH_SEP else system_separator # separator can be determined at the start # Yes... I know this is ugly and over engineered sparator = _get_separator(_get_separator_local() if run_type == 'local' else _get_separator_blob()) def _clean_path(path: str) -> str: return re.sub(fr"{separator}+", f"{separator}", path) def _read_text_local(filename): with open(filename, 'r') as file: return file.read() def _read_text_blob(filename): # I have no idea if container is a parameter or if you can get it here container = ... stream = read_blob(container, blob_path, use_lease=True) return stream.read().decode('utf-8') public = { "path_join": _path_join_local if run_type == 'local' else _path_join_blob, "clean_path": _clean_path, "read_text": _read_text_local if run_type == 'local' else _read_text_blob, } 

The optimist in me would now expect the above used as follows:

from pkg import public as util util.path_join(["aesd", "unqwfav"]) util.read_text("jazbec") 

The super optimistic claim would be that the following would be possible:

from pkg.public import path_join, read_text ... 

but I don't think that is how python works.

Anyways, this is the idea: have public object configured on startup by some sort of a factory (the factory "methods" in this case are the ternary expressions defining the public object properties). Hopefully this makes sense, but I feel like it really overcomplicates the code. It might be of some help if these were split into multiple files.

In OOP style, you would create a class that contains all the functions let say for server mode. Then you derive a new class from the first, that inherits all the functions. Here you can overwrite the functions that are different for local mode.

Now you can create instances (objects) from the one or other class, depending on your mode. That way you always call the right function without decision.