Sinatra - as a newbie.

I've been using Sinatra for a couple of Ruby projects lately and have found it to be easy to pick up and get running quickly. 

I've tried to answer some questions to help newbies like me in this post by Satish Talim. Hope it helps.

Will try to share some more inputs on my experiments with Sinatra in the days to come.

State pattern : Java and Ruby comparison

I've been working with Java as a programming language for long now and just started learning Ruby a few weeks back. Here I present a comparison between the two while trying to implement a basic State pattern. The reason I compare these examples is that they highlight the difference in the way these languages enable Design by contract.

In both examples clients of the StateExample class call its transition() method with a criteria parameter to change it's state. 

Java implementation

The StateExample class has a reference to an implementation of the IState interface. The transition() method delegates itself to the evaluate() method of the IState implementation which evaluates the criteria and returns either itself or a new IState implementation. Basically this allows the Implementation of the State to be abstracted to the interface IState and the StateExample class works on the contract specified by IState.

Ruby Implementation

Let's now look at the Ruby implementation of the same example. The StateExample class looks almost similar to it's Java counterpart. What's noticeable here is the absence of the equivalent of interface IState. 
Duck typing in Ruby allows this. The object referenced by the current_state variable only needs to contain an evaluate() method. The contract is therefore on the behaviour of the value of current_state rather than it's type.

Conclusion

Design by contract seems to be subtler and more implied in Ruby as compared to being typed in Java. For someone coming from Java, programming in a dynamically typed language like Ruby separates the concepts of Object oriented programming and Java language semantics. I can't help imagining Morpheus asking me to "Free your mind" :).

Test Driven (Design &) Development

I have been following Test Driven Development (TDD) for a few months now. 

Some of the direct benefits that I've seen are:

• Highly improved productivity due to minimal & accurate development.
• Highly improved code quality as I can refactor without fear of breaking something.
• A mental pat on my back whenever my tests are green-lighted :). i.e it is fun.

I have been trying to spread this practice at the workplace for the past few months with little success. My "sales pitch" typically revolves around the points mentioned above and I've had little success.

As I use TDD more and more, what I have come to realize is that not only has my code become cleaner now, my designs are more robust and flexible. I think to a large extent this is due to the fact that TDD tends to negate the effects of design prejudices.

Here is another blog that echoes some of the points mentioned here.

I am currently reading Test Driven Development : By Example by Kent Beck . Will publish a review once done reading. Something that has really taught me TDD has been the XP episode by Robert C. Martin and Robert S. Koss.

Single Responsibility Principle

Every once in a while one comes across a concept that he always knew was right but did not know how to apply. For me the concept of writing methods/functions having one(and only one) purpose was one such thing.

What is Single Responsibility Principle (SRP)?

Functions should do one thing. They should do it well. They should do it only. - is how Robert Martin describes this concept in his book Clean Code¹(which I would highly recommend). The issue with this has been to understand: what is one thing? Methods are written to do one operation after all so how do you determine the "one thing" that needs to go into the method. A quick review of any long method is typically enough to figure out what parts of code can be extracted into another method. How much to extract and where to stop is something that I've struggled with till recently. Let me try to explain these concepts using some material from Clean Code and some of my experiments.

How to determine whether a method is having single responsibility?

Sometimes the name of the method itself reveals that there are multiple responsibilities with the method. Does the method reads like an algorithm is what I like to check. Preferably like an algorithm that is simple to understand in one reading for someone who does not understand too much of programming. 

Robert Martin in his book Clean Code describes this as "In order to make sure our functions are doing “one thing,” we need to make sure that the statements within our function are all at the same level of abstraction." Now what does this mean? 

Basically it means that if your method's responsibility is to make a cup of coffee, it should just make coffee. It shouldn't be concerned with the act of visiting the grocery store to buy the Nescafe, sugar, etc. These related activities can be abstracted to respective methods/objects. This helps focus on the act of making the coffee right, irrespective of what happened while buying sugar. The same concept in turn would apply to the act of buying groceries and so on.

Here's an example of re-factoring code to have a single level of abstraction.

	public void remove(String string, int quantity) {
	Iterator<Map<TaxableItem, Integer>> itemMapIterator = _items.iterator();
	int itemIndex = -1;
	while (itemMapIterator.hasNext()) {
	Map<TaxableItem, Integer> itemMap = itemMapIterator.next();
	TaxableItem item = itemMap.keySet().iterator().next();
	if (item.getName() == string) {
	itemIndex = _items.indexOf(itemMap);
	}
	}
	if (itemIndex >= 0) {
	Map<TaxableItem, Integer> itemMap = _items.get(itemIndex);
	Iterator<Integer> quantityIterator = itemMap.values().iterator();
	int itemQtyinBasket = quantityIterator.next();
	if (quantity >= itemQtyinBasket) {
	_items.remove(itemIndex);
	} else {
	Iterator<TaxableItem> itemIterator = itemMap.keySet()
	.iterator();
	TaxableItem item = itemIterator.next();
	itemMap.put(item, itemQtyinBasket - quantity);
	}
	}
	}

view raw remove_bad_code.java hosted with ❤ by GitHub

The above code tries to remove a certain quantity of an item from a Shopping Cart by iterating through an internal data structure. It is pretty clear from this code that the level of detail spans at least 3 levels of abstraction from the intent expressed by the method name.

Here's the same method after a first pass of refactoring.

	public void remove(String name, int quantity)
	throws ShoppingBasketException {
	ShoppingBasketItem sbItemToRemove = findItemFromBasket(name);
	if (sbItemToRemove != null) {
	if (quantity > sbItemToRemove.getQuantity()) {
	itemsInBasket.remove(sbItemToRemove);
	} else {
	sbItemToRemove.reduceQuantityBy(quantity);
	}
	}
	}

view raw remove_better_code.java hosted with ❤ by GitHub

We can see from the code above that the task of finding the reference of the item in the Shopping cart has been abstracted to another method. There is still however some code that decides how to remove the item from the cart that can further be exracted.

	public void remove(String name, int quantity)
	throws ShoppingBasketException {
	ShoppingBasketItem sbItemToRemove = findItemFromBasket(name);
	performRemove(sbItemToRemove, quantity);
	}

view raw remove_final_code.java hosted with ❤ by GitHub

	private ShoppingBasketItem findItemFromBasket(String name) {
	Iterator<ShoppingBasketItem> itemIterator = itemsInBasket.iterator();
	while (itemIterator.hasNext()) {
	ShoppingBasketItem sbItem = itemIterator.next();
	if (sbItem.getName().equals(name)) {
	return sbItem;
	}
	}
	return null;
	}
	private void performRemove(ShoppingBasketItem sbItemToRemove, int quantity)
	throws ShoppingBasketException {
	if (sbItemToRemove != null) {
	if (quantity > sbItemToRemove.getQuantity()) {
	itemsInBasket.remove(sbItemToRemove);
	} else {
	sbItemToRemove.reduceQuantityBy(quantity);
	}
	}
	}

view raw find_performRemove.java hosted with ❤ by GitHub

This version of the code reads like an algorithm which goes:

1. Get a hold of the item that needs to be removed.
2. Remove it appropriately.

As can be seen, the extracted methods themselves go one level of abstraction below the intent stated by it's name. Also a noticeable side effect is that this led to the discovery of the ShoppingBasketItem object.

How much to extract?

You will know when to stop extracting when the code in an extracted method almost exactly matches the name of the method.

Benefit of SRP.

One obvious benefit of SRP is enhanced readability. Other benefits of SRP is that one may discover new Objects while extracting code into Methods.

How to refactor?

Martin Fowler in his book Refactoring stresses on the point of having a solid set of unit tests before refactoring code. 
A typical refactoring should include:

• Create a set of test cases to test the functionality of the method being refactored.²
• Iterate through refactoring and testing (using unit tests) till you reach the required level of abstraction for each method.

Conclusion

Single Responsibility Principle is a great guideline to make code readable. It will lead to an increase in the number of methods in the class or number of classes. The code will however express a clear and crisp flow of logic within and among the units.


Excerpts from Clean Code - Robert Martin and Refactoring - Martin Fowler. Code snippets and example are my own.


1. A highly recommended book.
2. The above refactoring exercise was backed by a set of unit tests which validated the functionality of the method.