I don’t know if you realized it or not, but we have just started cooking a nice bowl of “spaghetti” code. But wait! The business has a couple of other requirements, and we need to implement them. Here we go!

• FizzBuzz, or division by 15, should only happen on Saturdays and Sundays
• In case of FizzBuzz on week days, on Fridays it should be handled by 5, and other days – by 3
• Lucky Seven should only happen on Sundays, but in case of 105 on Sunday – which is 3*5*7, FizzBuzz should take a precedence.
• The rest of operations should run as usual

So, genius mind of GeneUs developer came up with this amazingly simple solution:

1. Create a package folder called “fizz_buzz_validators”, call each strategy object “validator” and put it there
2. Import validators and add them to the list of validators
3. Names of validators, such as “val_03”, “val_02”, etc., determine their order
4. Iterate over the list for each number. Because we have “fail fast” clause at the beginning, each validator will return either a valid result or a False boolean value which we will use

Hope you saw the issue with the code in section 8. Even though I put strategies in separate objects, which is good, I’m still importing them manually. And that creates very tight coupling between all those pieces. I have accomplished nothing!

First, I will take hardcoded objects names out of my code. I mean completely! Lines 7-13 show hard-coded values in this example. However in reality I would bring them from configuration file. Then lines 15-16 use values from the list of validators to import specified objects dynamically! My code doesn’t care about hardcoded values any more! Nice!

The code in part 9 has two major issues.

1. There’s no separation of concerns. The same is importing and validating (lines 16 – 17)
2. And this is a big one! The code is initializing each object for each number! What’s a problem? For just one number, there’s none. What if we feed 100,000 numbers to check? Or more?

The factory I designed is solving these issues. It is taking the task creating list of validators out of main code, and it is only doing it once per application run. Still, “_validators” will come from outside.

I thought my coding insanity would not be complete without introducing this approach. I am not sure I’d use it for this application, but it sure has time and place.

In this version I use os.listdir(path) to get a list of files in specified folder. I set default value to ‘fizz_buzz_validators’ for the sake of this demo only. This means I don’t even need a list of validators. As long as the object is in specified folder, this Factory will pick it up! Awesome! Validators have to start with “val” and have .py extension to be considered by my Factory. This will eliminate other files, like __init__.py.

I am also using “typing” package here to specify “-> List[str]” and “-> List[Callable[int], str]]”. Just like before, this means nothing for Python, but it helps me to remember, for example, that property “validators” returns a list of callable objects, functions, which take ‘int’ as input and returns ‘str’ as output.

Now is a good time to put our factory to work. Let’s look at the code.

I am importing my factory class. Yes, hardcoded for this demo. Using dependency injection is a little bit outside of the scope of this article. So direct import will do for now.

Then I am creating an instance of the factory, return a list of validators (line 14). And then looping to get through the numbers, just like a good FizzBuzz should’ve done to begin with. Except now we can scale our FizzBuzz up to MegaFizzBuzz with very little modifications.

Let’s take a look how it works. But don’t go too far. We have a curveball coming, I can see that…

Now it is a good time to enjoy the results of out Object Oriented FizzBuzz. It is definitely working!

First of all, look at Number 21. It is Fizz. Of course, I implemented the original algorithm here, where division by 7 is checked after division by 3. In section 8 I showed you the order of my validators, and it was based on the file name (val_01…, val_02…, etc.) That is a big problem!

If you remember what I wrote in Section 4 and especially Section 5, you know that requirements can and will change no matter how perfect the code is. And this code does not offer much flexibility. Yet. Even after all objects have been disconnected, nothing is replacing the “if” selection algorithm we had in the original algorithm. And that means if requirements change, we have no way to implement them.

So my admiration for my design had only lasted until Number 21. That kind of ruined it, but better now than later. Let’s fix it!

For the sake of simplicity, I will only implement one requirement: division by 7 should take precedency over division by 3 or 5 on Sundays.

“Rules” is another OOP Pattern used to separate logic rules from the business logic. I will implement it here, and this will be the last design pattern for this article.

I will implement the requirements from Section 4 – Division by 7 should only happen on Sundays before 3 and 5. And the block with “if” statements did nothing except defining the sequence of pieces of code. Those that I split into separate validator objects.

So instead of running “if” statements, I will simply create a sequence I need. “IF” logic was checking the day of the week, and if it was Sunday, then division by 7 was checked. Easy. And now I will not even need day_of_the_week into my code. I just need an object which defines that sequence. And another module will supply the “rules” to my factory. Here I did it in JSON file, but you can do it any way you want.

The “Rules” pattern can use classes as rules objects. But in this case I thought I could use JSON file. And now I need a Rule class, an object that will get the rule and bring it to me in consumable form. Kind of like “Factory” for the rules.

It is taking the name of the rule_file, and its property will give us a list of validators to bring into process. Not only this allows us to change the sequence of rules, we can define as many rules as we need, and we only add to the sequence those we need for the particular process.

Since I started putting rules and validators here, I think you may need to look into the “L” of SOLID. It stands for Liskov Substitution Principle.

I know, I know, Python does not have concept of interfaces, like C#, for example. Neither does C++. However, both Python and C++ have “Abstract Base Class”, and that’s what I would use in this case. The package “abs” (yes, it stands for “abstract base class” is exactly what I will be using here to put it to practice. Just in case I would need more Rule Factories in the future. Or maybe I am just adding it for fun, I let you decide.

In these two pieces of code you see the Rules_Base class with @abstractproperty, and you see Rule class implementing this base class. This Rule object is what I will pass into my Factory to get validators.

Finally I have a Factory which I most likely leave alone. Here’s what we have so far:

• The Factory is a class which expects another rules class implementing Rule_Base abstract class. Like I wrote a couple of times here, Rules_Base annotation is just a hint for developers, not a type check.
• Variable ‘path’ is optional here. I put it for the sake of this demo. In reality I would most likely create a class composition, an object containing all necessary info for the Factory. Including rules objects as one of its attributes
• Factory does not care about rules and sequences. It delegates this task to rules object, and its only job is to take a list of validators and return a list of objects those names represent

Not the original code from Section 1, but we are back inside the main module of the application.

• The rule, in this case ‘rule_lucky_sunday.json’ should be supplied by another dispatcher class. This should not be a concern of our application. Nor do we need to know what day of the week it is. Just give us the rule to follow today.
• On line 15 we pass the rule name into Rule object r(str), which becomes an argument for validators Factory val(Rule_Base).
• The property .validators of the Factory returns a list of validators
• Now we can iterate over validators and call .validate(int) function to determine if the number fits the criteria. The first valid response will return the value.

Finally, I got the result I was looking for. Number 21 is “Lucky Seven!” This happened because I used the rule “rule_lucky_sunday”. If I need another rule, I would need to pass it as an argument into the Rule object. While you are taking a moment to admire my work, I will mention several items I would need to add/modify in this application.

1. I am not checking if the arguments are valid. This is called “fail fast”. I won’t go in real code without that.
2. I am a fan of defensive programming style, so propagating exceptions is not acceptable. All possible exceptions have to be contained within the scope where they happen.With no exceptions! (Yes, pun intended)
3. Adding configuration file for those string variables, possible dependency injection. For production code I would need to do that.
4. Most likely, if I follow OOP style, I would favor classes as opposed to just functions. But I also like using functional approach, so I like and I will use functions as arguments or return types.

This obviously was not a code for production, but I think it can give a pretty good idea about some programming techniques that can easily turn such a nightmare application, like FizzBuzz, into a state-of-the-art Object Oriented Design!

Here’s the overview of the workflow in the final version of my application

1. FizzBuzz module is called by another process. Whatever that process is, it needs to supply the name of the “rule” object FizzBuzz needs to follow at each specific execution. It does not care about dates, time or any other outside circumstances. Juts the name of the “rule”.
2. FizzBuzz calls the Rule dispatcher (or Rule Factory) with the name of the rule.
3. It receives the concrete implementation of the rule. In case of this application, the rule looks like a list of validation objects we need to use in a specific sequence to validate the number.
4. FizzBuzz is sends rule object (a sequence) into a Factory
5. Factory uses a list of validators to look for objects
6. Factory imports those objects into the process, and it creates a list of objets according to the rule object
7. FizzBuzz receives a list of validators as a response from Factory
8. Finally, FizzBuzz takes the numbers and validates each one against the list of validators. The answer will be sent to the initial caller, and in our case just printed to the console (or terminal) window.