Introduction
Whether cooking up a new class and its methods or adding a new method to an existing class, you should keep one eye on the bigger picture to minimize duplication. Code duplication can, at times, be blatantly present and other times not as such. The key is identifying duplicate code no matter how subtle or in however big a class may be. When adding or updating a method, it’s essential to be aware of the other methods available in the class. With an understanding of the class’s motivation, identifying opportunities to refactor out duplicate code becomes an easier task.
1. Obvious code duplication
Some methods have values or behaviours included in their method names and when an additional method is needed that would ‘naturally’ fit as being very similar with a slight change of the mentioned method name value. That’s if you encounter a well-named method name. The method name does not always guarantee the critical aspects of its functionality, so reading into the details of a ‘similar’ method might be worth the effort. Note: One might be discouraged if encountered with a long method that seems to go on and on that might best be suited for a procedural programming language. That’s covered in another post.
Once such a method is identified, add a parameter to the method, rename the method and make the changes to the code that use the newly added parameter. Use other refactoring techniques to ensure no manual work is incurred.
2. Subtle code duplication
Code duplication identification may not always be at the method name level. Within the method’s implementation is a good place to look for opportunities to eliminate duplicate code. We’ll go over an example of such a scenario however be suspicious of methods that do ‘too much’ and do not rely on private methods to make themselves more concise. This task is easier undertaken with classes that exhibit high cohesion and that are loosely coupled. The more muddled the class in what it does the more of a refactoring effort will be needed not only to remote duplication but to align it more with best practices.
So, if two method implementations are doing similar work, consider extracting a new parameterized method or updating an existing method to serve both methods.
To a certain extent, identifying subtle code duplication can be a journey in itself, an acquired skill or even down to an art.
Whether cooking up a new class and its methods or adding a new method to an existing class, you should keep one eye on the bigger picture to minimize duplication. Code duplication can, at times, be blatantly present and other times not as such. The key is identifying duplicate code no matter how subtle or in however big a class may be. When adding or updating a method, it’s essential to be aware of the other methods available in the class. With an understanding of the class’s motivation, identifying opportunities to refactor out duplicate code becomes an easier task.
1. Obvious code duplication
Some methods have values or behaviours included in their method names and when an additional method is needed that would ‘naturally’ fit as being very similar with a slight change of the mentioned method name value. That’s if you encounter a well-named method name. The method name does not always guarantee the critical aspects of its functionality, so reading into the details of a ‘similar’ method might be worth the effort. Note: One might be discouraged if encountered with a long method that seems to go on and on that might best be suited for a procedural programming language. That’s covered in another post.
Once such a method is identified, add a parameter to the method, rename the method and make the changes to the code that use the newly added parameter. Use other refactoring techniques to ensure no manual work is incurred.
2. Subtle code duplication
Code duplication identification may not always be at the method name level. Within the method’s implementation is a good place to look for opportunities to eliminate duplicate code. We’ll go over an example of such a scenario however be suspicious of methods that do ‘too much’ and do not rely on private methods to make themselves more concise. This task is easier undertaken with classes that exhibit high cohesion and that are loosely coupled. The more muddled the class in what it does the more of a refactoring effort will be needed not only to remote duplication but to align it more with best practices.
So, if two method implementations are doing similar work, consider extracting a new parameterized method or updating an existing method to serve both methods.
To a certain extent, identifying subtle code duplication can be a journey in itself, an acquired skill or even down to an art.
No comments:
Post a Comment