Method Implementation

A Few Thoughts About Method Implementation

by on September 30, 2013 8:39 am

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!

— Robert Rice, asktheteam@keyholesoftware.com

  • Share:

One Response to “A Few Thoughts About Method Implementation”

  1. Phil says:

    Back in the olden days of OOP, the idea was that you had self-contained objects that communicated with each other through messaging. I think I might revise Uncle Bob’s preferences to each parameter ideally have 0 or 1 arguments. It should definitely not be a goal to have parameterless methods, because that way of thinking will lead you down the path of blocks of code managing their own dependencies (and cats and dogs sleeping together).

    The flip side, of course, is that these messages were supposed to contain everything a method would need to do its job, so it could be a primitive type all the way to a many-faceted object. Long chains of parameters are definitely a code smell no matter how you look at it and at the very least are signs that your logic is probably too complex to implement in a single method as opposed to encapsulating the different scenarios.

Leave a Reply

Things Twitter is Talking About
  • RT @JIRA: #Agile teams webinar starts in 30 mins. It's not too late to register: http://t.co/WrpAXnvKMr
    October 23, 2014 at 1:35 PM
  • Pssst... Our free monthly newsletter comes out tomorrow with dev tips/articles via email. Not on the list? Sign up: http://t.co/F8h0NSzleZ
    October 22, 2014 at 1:46 PM
  • How do we harness the power of callbacks without the confusing mess of nested functions in #JavaScript? Promises - http://t.co/obK811q48q
    October 21, 2014 at 2:18 PM
  • Pssst... Our free monthly newsletter comes out tomorrow with dev tips/articles via email. Not on the list? Sign up: http://t.co/F8h0NSzleZ
    October 21, 2014 at 12:05 PM
  • Did you know today is Clean Your Virtual Desktop Day? It really is: https://t.co/TCRpWgTmxg Celebrate by organizing your desktop files.
    October 20, 2014 at 4:50 PM
  • Don't miss the newest post from @bricemciver: Make Me a Promise - http://t.co/obK811q48q #JavaScript
    October 20, 2014 at 10:43 AM
  • RT @DZone: #Docker 1.3 Releases with Security, Signed Images, and Process Injection by @bendzone #devops http://t.co/uytIwFPgO6
    October 17, 2014 at 10:04 AM
  • If you have 15+ years #Java exp, you don't expect to be puzzled debugging a null pointer exception. See an exception: http://t.co/m2iDgNEleK
    October 17, 2014 at 9:51 AM
  • Many on our team attended the #Royals victory last night & @cdesalvo even got a selfie with the Gov. Go #KansasCity! http://t.co/N1Psooe2CE
    October 16, 2014 at 3:39 PM
  • Interesting ExplainLikeI'm5 talk: Why do companies develop iOS first when Android holds 70% of the 'Smart' Market? http://t.co/fxgjIBmqBi
    October 16, 2014 at 12:26 PM
  • We're looking for a top-notch #Java developer to join our team. Learn more about our company culture & the role - http://t.co/0fKsFmN0Ql
    October 16, 2014 at 9:08 AM
  • Want to learn to create custom #Java annotations & process them using the Reflection API? @jhackett01's tutorials - http://t.co/mf1F3eIDY3
    October 15, 2014 at 11:43 AM
  • Happy Ada Lovelace Day! It's a celebration of the achievements of women in STEM - if there's a woman in tech that you admire, tell her today
    October 15, 2014 at 9:13 AM
  • .@fpmoles We absolutely agree - thanks for reading!
    October 15, 2014 at 8:13 AM
  • With 15 yrs exp, @bmongar didn't expect surprise when debugging a null pointer exception. Why it puzzled him - http://t.co/m2iDgNEleK #Java
    October 14, 2014 at 11:20 AM
  • #Royals fans with tickets to tonight's canceled game, here's what you need to know - http://t.co/EErHht3zoN
    October 13, 2014 at 4:23 PM
  • RT @UzilitySoftware: Watch as Wayne explains to the boss, Marvin, what an agile board is about. #scrumalliance #scrum http://t.co/5MzB1bNw…
    October 13, 2014 at 12:01 PM
  • Getting started with #MongoDB? (Flexible #NoSQL for Humongous Data) Here's a free cheat sheet from the folks @Dzone - http://t.co/oBMvICzfcL
    October 13, 2014 at 11:10 AM
  • Brad Mongar's newest post is live on the Keyhole blog - #Java and the Sweet Science http://t.co/m2iDgNEleK
    October 13, 2014 at 8:59 AM
  • RT @housecor: If users have share links to your web app like this: "Go to here. Then click here. Then here." You're doing it wrong. #de
    October 10, 2014 at 2:18 PM
Keyhole Software
8900 State Line Road, Suite 455
Leawood, KS 66206
ph: 877-521-7769
© 2014 Keyhole Software, LLC. All rights reserved.