Remove Parameter

Introduction

• Caution when removing a parameter

Unlike adding method parameters, removing method parameters is not as popular. While adding parameters carries certain risks (see add parameter entry), removing parameters should also be carried out with equal concern.

1. Is the parameter simply not used?

Don’t overlook that unused method, if it’s not being used in the implementation then get rid of it. This leads to the a diluted method signature and potentially superfluous client processing to retrieve the parameter to satisfy the method signature. Unless null is passed in (see number 2 in this list) which doesn’t do anyone any favours. If it’s not being used, trash it!

2. Can certain method invocation combinations tolerate null values?

Calling a method with a null parameter is something that should be avoided. Such practice is risky as the method consumer know of the method’s implementation details. This introduces a risk when the implementation changes and a null value is no longer tolerated, the result will be potential null pointer exceptions. No one likes null pointer exceptions. This proves even more so when developing in an IOC environment where the consumers are only aware of interfaces not implementations. And even more so when you don’t have access to the implementation details and the tolerating of null values was somewhat of a ‘discovery’.

Make sure to introduce overloaded method signatures when developing an implementation that tolerates null values with certain parameter combinations.

3. Parameters belong in a single class?

Sometimes a group of different parameters that make up a method signature can indeed form part of an existing class or motivate you to create a new class to encapsulate them. The creation of a new class (if indeed it makes sense) will make the method signature more concise and potentially reduce parameter validation for each parameter with the method. The validation can be moved to the newly created class. The original method becomes less cluttered with parameter validation and more cohesive just focusing on what it should be doing.

4. Would the method benefit from using a parameter object or an aggregate object?

At times a methods require the same data from many different sources, data that does not make sense to exist in a single class. In such a case, a parameter object (typically a simple bean) is used instead of methods with multiple parameters which can lead to client consumption confusion. Another approach is to create an aggregate class that is constructed using multiple class that contain the data needed. The aggregate class is responsible for not exposing containing objects but rather only exposing their relevant data through its own methods. The aggregate approach should only be adopted if the class and the data it exposes make sense to be contained within an aggregate class.

5. Is the type expressive of the parameter data?

Okay, so this isn’t exactly removing a parameter but it does carry a similar amount of refactoring. When an existing parameter type does not concisely represent the actual data then it’s worth removing and adding (effectively replacing) a parameter to help callers consume the method with more confidence. Typically, parameters represented as primitives or String types are potentially candidates for further investigation. A case I come across is that of id where the id is represented as a String. The consumer can easily consume the method with any old string value and will probably encounter runtime exceptions if the string value does not adhere to the expected id format. In this case, it would be more helpful to consumers to change the type from String to URI, UUID or some custom id class. With this approach there’s no guessing from the consumer as to what format the id should be in.


Manual refactoring (REPEAT from Update method name lesson)

Now, let’s see how to become a refactorKing using Eclipse
todo....