What Refactoring is a tool used for making code more readable and understandable to humans, thereby maintainable. It does not effect the functionality. In fact it should not effect the functionality. Why Refactoring is necessary when you have other people reading your code. For that matter, if you revisit your code after a break, you may also find it difficult to understand. Refactoring also makes it easier to add new functionality and for others to utilize it in their code. So it is important to refactor code. How Let us look at the following example. Suppose I need to write a program as follows: Name: ‘ ’. extract-properties Description: Extracts and prints value of properties from file Input: (of type — xml | property | json ..) and file property names of values to extract (replaces the dynamic map key (if) found in the property values, with corresponding map values.) dynamic map Now we can split the problem into smaller problems as: properties from given file ( method should support file types like — xml, property, json.) Extract Extract placeholders with dynamic values Replace There are three ways to solve the problem. Procedural Object Oriented Functional Lets evaluate all three. Procedural Procedural way of solving the problem, method reads file content and calls method. main extract method parses the content based on type, using an if condition that calls the specific parse method and extracts the properties and returns these properties. extract method now call method to replace the placeholders with its dynamic values. main replace Now suppose you need to add another handler, say ‘YAML’ file type. You will need to : Add another if else block in ‘extract’ method. Advantages of the above approach: Ease to write when extensions/modification are limited. What are the disadvantages of the above approach? This causes a bottleneck on the extract method. In a team of developers, constant updates to a single entity by all the developers will result in merge conflicts. The extract method will increase in size as extensions are added. This will make it less readable. Having business logic interspersed with your I/O operations will result in unit test cases that will need actual resource versus a mock. The resource I/O operations code cannot be reused in other parts of the code as it is tightly coupled to the business logic. Object Oriented Let’s have a base class . This defines methods extract () and . needs to allow for custom implementation to support future enhancements. While needs to be common logic to be used irrespective of the custom extract implementation. ResourceHandler replace () extract() replace() We can model this as follows: As you see ResourceHandler has methods: handle(). This contains the business logic, which for our purposes can be as simple as: {
  extract();
  replace();
} Map public handle () protected abstract void extract() - contains logic to extract properties from file private void replace() - contains logic to replace properties from dynamic map Now the abstract method ‘extract’ needs to be overridden by its child classes: XmlResource JsonResource PropertiesResource Below is the main class. Advantages of this approach: This structure allows to add new extensions without modifying the base ‘handler’ method, that is invoked to extract and replace properties. So child classes cannot corrupt the business logic. There is no more a bottleneck on the extract method as it was with the procedural code. Now each custom extract method has it’s own implementation in it’s own class. This will reduce the possible merge-conflicts between multiple developers working on different custom extract implementation. Object ‘ResourceHandler’ is closed for modification while being open for extension. This is one of the pillars of the principle. For example if, ResourceHandler is shared as jar, it can still be extended to support additional resource types, but the underlying base logic is still restricted. SOLID Disadvantages: The IO logic to extract properties for given type, is still coupled to the business logic, due to the structure of the Base class. As the only public method is handle, which calls the extract method and replace method. So we cannot use extract in isolation. Functional Lets implement functional code using interfaces as follows: ResourceHandler interface defines a single method ‘extract’ that takes the file and list of properties to extract, and returns the corresponding extracted properties from the input file. We will utilize the ResourceHandler in the business logic, and inject the specific implementation in to the class ExtractReplace that encapsulates the business logic as follows: { Map extracted_properties; {
    Map props = handler.extract(file, properties);
    extracted_properties = replace(props, dynamic);
  } {...} { extracted_properties.toString();
  }
} class ExtractReplace private public ExtractReplace (File file, List properties,Map dynamic, ResourceHandler handler) Map private replace (Map properties, Map dynamic) @Override String public toString () return Now the main class will look like this: The main class creates an object of type ExtractReplace by passing an implementation of ResourceHandler Interface via the Lambda construct as seen. This demonstrates the capability to define adhoc anonymous implementations which do not need to be housed in a type of it’s own, thereby reducing structural complexity. We can also follow a more structured approach, where the different flavours of ResourceHandlers are housed in their own types. This structure allows to use XmlHandler/JsonHandler … objects independently for extracting properties. This is an advantage over Object-oriented approach shown above. The main class can create objects of specific types of ResourceHandler and pass them to the ExtractReplace class as follows: You can further decouple the if-else code for instantiating ResourceHandler by having a builder class (Using Builder Pattern). The enhanced ExtractReplace class with ‘builder’ pattern will look like this: { Map extracted_properties; { File file; List properties; Map dynamic; ResourceHandler handler; { .file = file; .properties = properties; .dynamic = dynamic; (file.getName().endsWith( )) .handler = JsonHandler(); (file.getName().endsWith( )) .handler = XmlHandler();
  } { ExtractReplace( );
    }
  } {
    Map props = builder.handler.extract(builder.file, builder.properties);
  } { ... } { extracted_properties.toString();
  }
} class ExtractReplace private static class Builder private private private private Builder static getInstance (File file, List properties, Map dynamic) this this this if ".json" this new else if ".xml" this new ExtractReplace public build () new this private ExtractReplace (Builder builder) Map private replace (Map properties, Map dynamic) @Override String public toString () return More on the builder pattern . here Advantages: Over and above the advantages that are provided by Object Oriented approach, this also separates the extraction logic from the business logic. Hence you can reuse this extract method. You can follow a structured approach by creating different implementation classes of ResourceHandler, which can be resused. You can also follow a adhoc anonymous approach using Lambda functions. This is useful if you are not reusing the extraction logic else where and want to reduce the structural complexity. Final Notes The above functional code is an implementation of Strategy pattern, similar to Collections.sort, where you can pass a custom Comparator implementation. As you can see the code is extensible, easier to consume, understand and extend.

Different

Winner of Noonies 2020 for the award Hacker Noon Contributor of the Year - FUNCTIONAL PROGRAMMING.

Refactoring using Functional Programming

Too Long; Didn't Read

Company Mentioned

@arvindkgs

RELATED STORIES