A4 portrait - PET: Python Entre Todos - Python Argentina

First “non-dynamic” solution 26
First “non-dynamic” solution
To many one reading this, the first solution that will come to mind will be that each
method (actionX…) must have within itself a big if, for each service. Something like:
class Foo:
def action1(self, service):
if service == "A":
#code for action 1 in service A
elif service == "B":
#code for action 1 in service B
elif service == "C":
#code for action 1 in service C
elif service == "D":
#code for action 1 in service D
This will work, that I won’t deny. But… what don’t I like of this option? I don’t like:
1. That if will be repeated in each of the actions, of which there are 5. When we add
or modify services, I have to maintain the same if in all 5 methods “actionX”.
2. The code quickly becomes unreadable when there’s a lot to do per action.
3. It gives the sensation that we’re “mixing” apples and oranges, that this could be
better organized.
4. This ifs are two lines of code for each action and service, so with 5 actions and 4
services, that’s 40 lines of code only in ifs, not including the code for the actions
themselves. It’s 40 lines of code that don’t do what we want to do, that we need
only to decide what to do.
Enhancing the “non-dynamic” solution
For the apples and oranges and organizational problem, more than one will have had
the idea of something like this:
class Foo:
def action1(self, service):
if service == "A":
self.action1_in_A()
elif service == "B":
self.action1_in_B()
elif service == "C":
self.action1_in_C()
elif service == "D":
self.action1_in_D()
def action1_in_A(self):
#code of action 1 in service A
def action1_in_B(self):
#code of action 1 in service B
def action1_in_C(self):
#code of action 1 in service C
def action1_in_D(self):
#code of action 1 in service D
I can’t deny it, the separation in many methods does help legibility and
maintainability a tiny bit. Considering that part resolved, we forget about methods
“actionX_in_Y”. But we still have this:
PET: English Translation (Issue 1, August 2010) — http://revista.python.org.ar