Redesigned Code

We had a couple of shortcomings:

1. ConfigManager class is catering to multiple use cases

2. Method names in ConfigManager are to be changed in all places they’re used.

This redesigned version can be found inside the oop_way/ directory.

To combat the first issue, we go with an abstract class ConfigManager inside oop_way/config/config_manager.py. Abstract class? Yeah, we won’t provide any implementation in this class, just the method names. Other classes will then implement these methods based on the file types they need to support.

@abc.abstractmethod

def read_config(self, filename: str):

    print('Abstract method: Not implemented')

    raise NotImplementedError


@abc.abstractmethod

def write_config(self, filename: str, config_data: dict):

    print('Abstract method: Not implemented')

    raise NotImplementedError

Let’s look at what the method definitions are trying to say

1. read_config(self, filename: str) - sets an abstract method read_config which takes a single parameter, filename denoting the configuration file name. No, self isn’t another parameter but just denotes object of the ConfigManager class itself

2. write_config(self, filename: str, config_data: dict) - defines the abstract method write_config which takes two parameters, configuration file name & the configuration data to be written to the config file.

Now, the fancy annotation @abc.abstractmethod along with the __subclasshook__() method is required as Python doesn’t support abstract classes by default.

@classmethod

def __subclasshook__(cls, subclass):

    return (hasattr(subclass, 'read_config') and

            callable(subclass.read_config) and

            hasattr(subclass, 'write_config') and

            callable(subclass.write_config) or

            NotImplemented)

Now we have the method signature required for reading & writing configuration laid out clearly. Each configuration file type can be supported by a subclass of the ConfigManager class which will implement the specific read/write functionality of that type.

You can see that we have a class each for dealing with the JSON & XML configurations. Let’s check the oop_way/config/config_manager_json.py file.

class ConfigManagerJson(ConfigManager):

    CONFIG_FOLDER = 'oop_way/config_files/'

    FILE_SUFFIX = '.json'

    def read_config(self, filename: str):

        with open(ConfigManager.CONFIG_FOLDER + filename

                  + ConfigManagerJson.FILE_SUFFIX) as inputfile:

            try:

                config_data = json.load(inputfile)

                return config_data

            except:

                print('Seems the file is empty. Not a problem')


    def write_config(self, filename: str, config_data: dict):

        with open(ConfigManager.CONFIG_FOLDER + filename

                + ConfigManagerJson.FILE_SUFFIX, 'w') as outfile:

            json.dump(config_data, outfile)

            outfile.write('\n')

Some points we can comprehend from the code

• The ConfigManagerJson class is a subclass of the ConfigManager abstract class

• It implements both of the abstract methods defined in ConfigManager

Similarly, we have the implementation for the XML type configuration in oop_way/config/config_manager_xml.py

All done, right? Hmm, Not really!

Our earlier implementation had one more drawback - we were dealing with the issue of having to change method names and parameter values in all previous implementations, whenever support for a new config file type was added. This made the code harder to maintain.

How did we deal with this in our new implementation based on Abstraction?

Taking a look at the Logistics team’s implementation in oop_way/logistics_hardware.py

config_manager = ConfigManagerXml()


def store_mysql_config(mysql_config):

    print('Storing mysql config of logistics team')

    config_manager.write_config('logistics_mysql_config', mysql_config)


def store_logistics_rest_server_config(rest_server_config):

    print('Storing rest_server config of logistics team')

    config_manager.write_config('logistics_rest_server', rest_server_config)


def read_mysql_config():

    print('Reading mysql config of logistics team')

    mysql_config = config_manager.read_config('logistics_mysql_config')

    return mysql_config


def read_logistics_rest_server_config():

    print('Reading rest_server config of logistics team')

    rest_server_config = config_manager.read_config('logistics_rest_server')

    return rest_server_config

As the Logistics team moved to using XML, they are creating an object of the ConfigManagerXml() class and it’s methods for reading & writing configuration as XML type.

What would the Logistics team need to do if they were having second thoughts to go back to JSON itself? They’d need to just change config_manager to an object of type ConfigManagerJson instead of ConfigManagerXml. Done!

You can use the below command for running oop_way/main.py

python3 oop_way/main.py