About Keyhole Software

Keyhole is a midwest-based consulting firm with a tight-knit technical team. We work primarily with Java, JavaScript and .NET technologies, specializing in application development. We love the challenge that comes in consulting and blog often regarding some of the technical situations and technologies we face.

A Few Thoughts About Method Implementation

In chapter 17 of “Clean Code” by Robert C. Martin, the author describes the idea of “code smells,” practices in development that, while they don’t explicitly violate any standards (whether unwritten or not), they leave behind a “stench” of inexperience or lack of discipline. I like this idea; it seems to me that I encounter these “code smells” fairly often (given the diverse teams I often work with) and they can make code difficult to decipher and maintain.

Take, for instance, the number of parameters on a method. According to Martin, optimally, there would be zero parameters, but any number up to and including three is acceptable. Three is an arbitrary number selected by the author, of course, but I think my own restrictions would fall within the same range, though it would certainly sometimes depend on the conditions. Sometimes it is just not possible to put such a restriction on the parameter list size, especially when working on an already established code base, but I do have some suggestions.

  1. Do a significant number of the parameters originate from the same object instance? Try passing in the containing object instead and refer to the attributes as needed inside the method.
  2. Alternatively, implement the method on the object itself, thus eliminating the need to refer to another object within the method.
  3. Sometimes, altering the parameter list is just not possible without a significant re-factor of the involved code. If the risk of the re-factor is too high (usually due to time constraints), one option is to build a transient object that encapsulates all of the attributes needed for the completion of the method’s function, passing this single object to the method, or again, alternatively, having the method exist on the transient object itself.

Another “smelly” practice is the idea of “output arguments.” There is an expectation that parameters should be merely an input to the method, and to not be altered by the logic of the method. It is suggested that this practice is holdover from pre-OOP days where output arguments would be necessary, but this is no longer the case. It is now better practice to think of the reserved word “this” as the output argument. Again, the best way to express this practice is to have the object affected by the logic implement the method on itself.

Flag arguments are booleans that are passed to the method, signifying that the behavior might be performing two separate functions. The better alternative to this is to implement the logic into two methods, one implementing the logic executed if the parameter is set to true, the other implementing the logic executed if the parameter is set to false. This forces you to also give more meaningful function names to both implementations, making the intention of each much more clear to whomever needs to use them. Sometimes a flag argument is used in this manner because both logic paths share a significant number of logic steps before the diverge from each other. If this is the case, you would be better off to create a third method that implements the common logic path, while still keeping the divergent logic in the other two methods.

One idea that the author did not mention, but which I felt was relevant to this topic, was the usage of a local method variable as the return value to a method as opposed to returning the object itself. To clarify, see the two implementation examples below. The first simply returns the number if the condition is met, while the second sets the number on a local variable and returns the variable at the end of the method.

int getNumber(){
		if(condition1){
			return 1;
		} else if(condition2){
			return 2;
		} else {
			return null;
		}
	}
int getNumber(){
		int returnValue = null;
		if(condition1){
			returnValue = 1;
		else if(condition2){
			returnValue = 2;
		}
		return returnValue;
	}

The second implementation I feel is superior for at least one reason. It is always abundantly clear where the method exits because it can only exit in one place. This makes it much easier to understand and maintain.

Finally, and simply, there is the “dead function,” the function that is not called anywhere in the system. Source control exists for a reason; use it!
 

Reference: A Few Thoughts About Method Implementation from our JCG partner Robert Rice at the Keyhole Software blog.

Do you want to know how to develop your skillset to become a Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

JPA Mini Book

Learn how to leverage the power of JPA in order to create robust and flexible Java applications. With this Mini Book, you will get introduced to JPA and smoothly transition to more advanced concepts.

JVM Troubleshooting Guide

The Java virtual machine is really the foundation of any Java EE platform. Learn how to master it with this advanced guide!

Given email address is already subscribed, thank you!
Oops. Something went wrong. Please try again later.
Please provide a valid email address.
Thank you, your sign-up request was successful! Please check your e-mail inbox.
Please complete the CAPTCHA.
Please fill in the required fields.

Leave a Reply


six + 4 =



Java Code Geeks and all content copyright © 2010-2014, Exelixis Media Ltd | Terms of Use | Privacy Policy | Contact
All trademarks and registered trademarks appearing on Java Code Geeks are the property of their respective owners.
Java is a trademark or registered trademark of Oracle Corporation in the United States and other countries.
Java Code Geeks is not connected to Oracle Corporation and is not sponsored by Oracle Corporation.
Do you want to know how to develop your skillset and become a ...
Java Rockstar?

Subscribe to our newsletter to start Rocking right now!

To get you started we give you two of our best selling eBooks for FREE!

Get ready to Rock!
You can download the complementary eBooks using the links below:
Close