Long Methods? Try Compose Methods

We all have seen long winding code that goes on and on. By the time you have hit page down a couple of times, you forget what the method was doing. You forget because the method is doing a lot. It is failing the SRP principle and needs to be broken down into smaller pieces. According to me if you are looking at a method and cannot figure out what it is doing in 5 secs then it needs to be rewritten.

Want to try, ok tell me what this method is doing

public class ListToMania{

	public void add(Object element) {
		if (!readOnly) {
			int newSize = size + 1;
			if (newSize > elements.length) {
				Object[] newElements = new Object[elements.length + 10];
				for (int i = 0; i < size; i++) {
					newElements[i] = elements[i];
				elements = newElements;
		elements[size++] = element;

5 seconds are up 😉

To give you some idea, this is the add method for adding a new element to the list. This code checks to see whether the size of the elements array will exceed capacity if a new object is added. If capacity will be exceeded, the elements array is expanded by a factor of 10.

Ok, now let us see if this could be simpler to read and work for the 5 second rule that we have

How about this one,

public class List.ToMania{
	public void add(Object element) {
		if (readOnly) return;
		if (isTheListAtCapacity()){

Does this one suggest what it is doing in 5 Secs? Sure it does.

Let us see what we have done,

We have tried to do is convert add(Object element) into a composed method. It is composed of many other methods. What this does is that it calls other methods. You can read a composed method within seconds and decipher WHAT it is doing. For understanding the HOW part you need to visit the methods that it is calling.

Our private methods now look like this

private boolean isTheListAtCapacity(){
	return (size + 1) > elements.length;

private void growTheList(){
	Object[] newElements =
 new Object[elements.length + GROWTH_INCREMENT];
	for (int i = 0; i < size; i++)
		newElements[i] = elements[i];
	elements = newElements;

private void addElement(Object element) {
	elements[size++] = element;

So using the compose method, you avoid having long methods, you also pass the 5 second understanding test. The caveat is that if there are too many methods in a composed method then you need to look if the composed method is doing a lot of things. Another problem is that if there are too many private methods then debugging would be tedious. However if you face any of these issues then probably your method is trying to do a lot in the first place.

About Vikas Hazrati

Vikas is the Founding Partner @ Knoldus which is a group of software industry veterans who have joined hands to add value to the art of software development. Knoldus does niche Reactive and Big Data product development on Scala, Spark and Functional Java. Knoldus has a strong focus on software craftsmanship which ensures high-quality software development. It partners with the best in the industry like Lightbend (Scala Ecosystem), Databricks (Spark Ecosystem), Confluent (Kafka) and Datastax (Cassandra). To know more, send a mail to hello@knoldus.com or visit www.knoldus.com
This entry was posted in Agile, Java and tagged , , , . Bookmark the permalink.

One Response to Long Methods? Try Compose Methods

  1. Pingback: Long Method? Move Accumulation to a Collecting Parameter « Inphina Thoughts

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s