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 interfaceConfigManager inside oop_way/config/ConfigManager.java. Interface? 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.

public interface ConfigManager {

    public <T> T readConfig(String filename, Class<T> configClass);

    public <T> void writeConfig(String filename, T configData);

}

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

1. readConfig(String filename, Class<T> configClass) - sets an abstract method readConfig which takes two parameters, filename denoting the configuration file name. configClass denotes the configuration type’s class. For MySql, this will be the MySqlConfig class

2. writeConfig(String filename, T configData) - defines the abstract method writeConfig which takes two parameters, configuration file name & the configuration data to be written to the config file.

Now we have the method signature required for reading & writing configuration laid out clearly. Each configuration file type can be supported by a class that implements the interface provided by ConfigManager. This class will implement the specific read/write functionality for 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/ConfigManagerJson.java file.

public class ConfigManagerJson implements ConfigManager {

    public static final String CONFIG_FOLDER = "src/main/java/com/example/abstraction/oop_way/config_files/";

    public static final ObjectMapper objectMapper = new ObjectMapper();


    public <T> T readConfig(String filename, Class<T> configClass) {

        T config = null;

        File filePath = Paths.get(CONFIG_FOLDER + filename).toFile();

        ObjectMapper objectMapper = new ObjectMapper();

        try {

            config = objectMapper.readValue(filePath, configClass);

        } catch (IOException ex) {

            System.out.println("Error on reading data");

        }

        return config;

    }


    public <T> void writeConfig(String filename, T configData) {

        File filePath = Paths.get(CONFIG_FOLDER + filename).toFile();

        ObjectMapper objectMapper = new ObjectMapper();

        try {

            objectMapper.writeValue(filePath, configData);

        } catch (IOException ex) {

            System.out.println("Error on writing data");

        }

    }

}

Some points we can understand from the code

• The ConfigManagerJson class is a subclass of the ConfigManager interface

• It implements both of the abstract methods defined in ConfigManager

Similarly, we have the implementation for the XML type configuration in oop_way/config/ConfigManagerXML.java

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/LogisticsHardware.java

public class LogisticsHardware {

    ConfigManager configManager = new ConfigManagerXML();

    

    public void storeMySqlConfig(MySqlConfig mySqlConfig) {

        System.out.println("Storing mysql config of logistics team");

        configManager.writeConfig("logistics_mysql_config", mySqlConfig);

    }


    public MySqlConfig readMySqlConfig() {

        System.out.println("Reading mysql config of logistics team");

        MySqlConfig mySqlConfig = configManager.readConfig("logistics_mysql_config", MySqlConfig.class);

        return mySqlConfig;

    }


    public void storeLogisticsRestServerConfig(RestServerConfig restServerConfig) {

        System.out.println("Storing rest_server config of logistics team");

        configManager.writeConfig("logistics_rest_server", restServerConfig);

    }


    public RestServerConfig readLogisticsRestServerConfig() {

        System.out.println("Reading rest_server config of logistics team");

        RestServerConfig restServerConfig = configManager.readConfig("logistics_rest_server",

                RestServerConfig.class);

        return restServerConfig;

    }

}

As the Logistics team moved to using XML, they are creating an object of the ConfigManagerXML() class and using its methods to read and write configuration XML.

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

Right-click inside oop_way/Main.java and select Run to run the file.