Tuesday, February 2, 2016

Top 10 Most Common Mistakes That Java Developers Make: A Java Beginner’s Tutorial

Java is a programming language that was initially developed for interactive television, but over time it has become widespread over everywhere software can be used. Designed with the notion of object-oriented programming, abolishing the complexities of other languages such as C or C++, garbage collection, and an architecturally agnostic virtual machine, Java created a new way of programming. Moreover, it has a gentle learning curve and appears to successfully adhere to its own moto - “Write once, run everywhere”, which is almost always true; but Java problems are still present. I’ll be addressing ten Java problems that I think are the most common mistakes.

Common Mistake #1: Neglecting Existing Libraries

It’s definitely a mistake for Java Developers to ignore the innumerable amount of libraries written in Java. Before reinventing the wheel, try to search for available libraries - many of them have been polished over the years of their existence and are free to use. These could be logging libraries, like logback and Log4j, or network related libraries, like Netty or Akka. Some of the libraries, such as Joda-Time, have become a de facto standard.

The following is a personal experience from one of my previous projects. The part of the code responsible for HTML escaping was written from scratch. It was working well for years, but eventually it encountered a user input which caused it to spin into an infinite loop. The user, finding the service to be unresponsive, attempted to retry with the same input. Eventually, all the CPUs on the server allocated for this application were being occupied by this infinite loop. If the author of this naive HTML escape tool had decided to use one of the well known libraries available for HTML escaping, such as HtmlEscapers from Google Guava, this probably wouldn’t have happened. At the very least, true for most popular libraries with a community behind it, the error would have been found and fixed earlier by the community for this library.

Common Mistake #2: Missing the ‘break’ Keyword in a Switch-Case Block

These Java issues can be very embarrassing, and sometimes remain undiscovered until run in production. Fallthrough behavior in switch statements is often useful; however, missing a “break” keyword when such behavior is not desired can lead to disastrous results. If you have forgotten to put a “break” in “case 0” in the code example below, the program will write “Zero” followed by “One”, since the control flow inside here will go through the entire “switch” statement until it reaches a “break”. For example:

    
public static void switchCasePrimer() {
     int caseIndex = 0;
     switch (caseIndex) {
         case 0:
             System.out.println("Zero");
         case 1:
             System.out.println("One");
             break;
         case 2:
             System.out.println("Two");
             break;
         default:
             System.out.println("Default");
     }
}
    

In most cases, the cleaner solution would be to use polymorphism and move code with specific behaviors into separate classes. Java mistakes such as this one can be detected using static code analyzers, e.g. FindBugs and PMD.

Common Mistake #3: Forgetting to Free Resources

Every time a program opens a file or network connection, it is important for Java beginners to free the resource once you are done using it. Similar caution should be taken if any exception were to be thrown during operations on such resources. One could argue that the FileInputStream has a finalizer that invokes the close() method on a garbage collection event; however, since we can’t be sure when a garbage collection cycle will start, the input stream can consume computer resources for an indefinite period of time. In fact, there is a really useful and neat statement introduced in Java 7 particularly for this case, called try-with-resources:

    
private static void printFileJava7() throws IOException {
    try(FileInputStream input = new FileInputStream("file.txt")) {
        int data = input.read();
        while(data != -1){
            System.out.print((char) data);
            data = input.read();
        }
    }
}
    

This statement can be used with any object that implements the AutoClosable interface. It ensures that each resource is closed by the end of the statement.

Common Mistake #4: Memory Leaks

Java uses automatic memory management, and while it’s a relief to forget about allocating and freeing memory manually, it doesn’t mean that a beginning Java developer should not be aware of how memory is used in the application. Problems with memory allocations are still possible. As long as a program creates references to objects that are not needed anymore, it will not be freed. In a way, we can still call this memory leak. Memory leaks in Java can happen in various ways, but the most common reason is everlasting object references, because the garbage collector can’t remove objects from the heap while there are still references to them. One can create such a reference by defining class with a static field containing some collection of objects, and forgetting to set that static field to null after the collection is no longer needed. Static fields are considered GC roots and are never collected.

Another potential reason behind such memory leaks is a group of objects referencing each other, causing circular dependencies so that the garbage collector can’t decide whether these objects with cross-dependency references are needed or not. Another issue is leaks in non-heap memory when JNI is used.

The primitive leak example could look like the following:

    
final ScheduledExecutorService scheduledExecutorService = Executors.newScheduledThreadPool(1);
final Deque numbers = new LinkedBlockingDeque<>();
final BigDecimal divisor = new BigDecimal(51);

scheduledExecutorService.scheduleAtFixedRate(() -> {
 BigDecimal number = numbers.peekLast();
    if (number != null && number.remainder(divisor).byteValue() == 0) {
      System.out.println("Number: " + number);
 System.out.println("Deque size: " + numbers.size());
 }
}, 10, 10, TimeUnit.MILLISECONDS);

 scheduledExecutorService.scheduleAtFixedRate(() -> {
 numbers.add(new BigDecimal(System.currentTimeMillis()));
 }, 10, 10, TimeUnit.MILLISECONDS);

try {
 scheduledExecutorService.awaitTermination(1, TimeUnit.DAYS);
} catch (InterruptedException e) {
 e.printStackTrace();
}
    

This example creates two scheduled tasks. The first task takes the last number from a deque called “numbers” and prints the number and deque size in case the number is divisible by 51. The second task puts numbers into the deque. Both tasks are scheduled at a fixed rate, and run every 10 ms. If the code is executed, you’ll see that the size of the deque is permanently increasing. This will eventually cause the deque to be filled with objects consuming all available heap memory. To prevent this while preserving the semantics of this program, we can use a different method for taking numbers from the deque: “pollLast”. Contrary to the method “peekLast”, “pollLast” returns the element and removes it from the deque while “peekLast” only returns the last element.

To learn more about memory leaks in Java, please refer to article on Toptal that demystified this problem.

Common Mistake #5: Excessive Garbage Allocation

Excessive garbage allocation may happen when the program creates a lot of short-lived objects. The garbage collector works continuously, removing unneeded objects from memory, which impacts applications’ performance in a negative way. One simple example:

    
String oneMillionHello = "";
for (int i = 0; i < 1000000; i++) {
    oneMillionHello = oneMillionHello + "Hello!";
}
System.out.println(oneMillionHello.substring(0, 6));
    

In Java, strings are immutable. So, on each iteration a new string is created. To address this we should use a mutable StringBuilder:

    
StringBuilder oneMillionHelloSB = new StringBuilder();
    for (int i = 0; i < 1000000; i++) {
        oneMillionHelloSB.append("Hello!");
    }
System.out.println(oneMillionHelloSB.toString().substring(0, 6));
    

While the first version requires quite a bit of time to execute, the version that uses StringBuilder produces a result in a significantly less amount of time.

Common Mistake #6: Using Null References without Need

Avoiding excessive use of null is a good practice. For example, it’s preferable to return empty arrays or collections from methods instead of nulls, since it can help prevent NullPointerException.

Consider the following method that traverses a collection obtained from another method, as shown below:

    
List accountIds = person.getAccountIds();
for (String accountId : accountIds) {
    processAccount(accountId);
}
    

If getAccountIds() returns null when a person has no account, then NullPointerException will be raised. To fix this, a null-check will be needed. However, if instead of a null it returns an empty list, then NullPointerException is no longer a problem. Moreover, the code is cleaner since we don’t need to null-check the variable accountIds.

To deal with other cases when one wants to avoid nulls, different strategies may be used. One of these strategies is to use Optional type that can either be an empty object or a wrap of some value:

    
Optional optionalString = Optional.ofNullable(nullableString);
if(optionalString.isPresent()) {
    System.out.println(optionalString.get());
}
    

In fact, Java 8 provides a more concise solution:

    
Optional optionalString = Optional.ofNullable(nullableString);
optionalString.ifPresent(System.out::println);
    

Optional type has been a part of Java since version 8, but it has been well known for a long time in the world of functional programming. Prior to this, it was available in Google Guava for earlier versions of Java.

Common Mistake #7: Ignoring Exceptions

It is often tempting to leave exceptions unhandled. However, the best practice for beginner and experienced Java developers alike is to handle them. Exceptions are thrown on purpose, so in most cases we need to address the issues causing these exceptions. Do not overlook these events. If necessary, you can either rethrow it, show an error dialog to the user, or add a message to the log. At the very least, it should be explained why the exception has been left unhandled in order to let other developers know the reason.

    
selfie = person.shootASelfie();
try {
    selfie.show();
} catch (NullPointerException e) {
    // Maybe, invisible man. Who cares, anyway?
}    
    

A clearer way of highlighting an exceptions’ insignificance is to encode this message into the exceptions’ variable name, like this:

    
try { selfie.delete(); } catch (NullPointerException unimportant) {  }
    

Common Mistake #8: Concurrent Modification Exception

This exception occurs when a collection is modified while iterating over it using methods other than those provided by the iterator object. For example, we have a list of hats and we want to remove all those that have ear flaps:

    
List hats = new ArrayList<>();
hats.add(new Ushanka()); // that one has ear flaps
hats.add(new Fedora());
hats.add(new Sombrero());
for (IHat hat : hats) {
    if (hat.hasEarFlaps()) {
        hats.remove(hat);
    }
}    
    

If we run this code, “ConcurrentModificationException” will be raised since the code modifies the collection while iterating it. The same exception may occur if one of the multiple threads working with the same list is trying to modify the collection while others iterate over it. Concurrent modification of collections in multiple threads is a natural thing, but should be treated with usual tools from the concurrent programming toolbox such as synchronization locks, special collections adopted for concurrent modification, etc. There are subtle differences to how this Java issue can be resolved in single threaded cases and multithreaded cases. Below is a brief discussion of some ways this can be handled in a single threaded scenario:

Collect objects and remove them in another loop

Collecting hats with ear flaps in a list to remove them later from within another loop is an obvious solution, but requires an additional collection for storing the hats to be removed:

    
List hatsToRemove = new LinkedList<>();
for (IHat hat : hats) {
    if (hat.hasEarFlaps()) {
        hatsToRemove.add(hat);
    }
}
for (IHat hat : hatsToRemove) {
    hats.remove(hat);
}
    

Use Iterator.remove method

This approach is more concise, and it doesn’t need an additional collection to be created:

    
Iterator hatIterator = hats.iterator();
while (hatIterator.hasNext()) {
    IHat hat = hatIterator.next();
    if (hat.hasEarFlaps()) {
        hatIterator.remove();
    }
}
    

Use ListIterator’s methods

Using the list iterator is appropriate when the modified collection implements List interface. Iterators that implement ListIterator interface support not only removal operations, but also add and set operations. ListIterator implements the Iterator interface so the example would look almost the same as the Iterator remove method. The only difference is the type of hat iterator, and the way we obtain that iterator with the “listIterator()” method. The snippet below shows how to replace each hat with ear flaps with sombreros using “ListIterator.remove” and “ListIterator.add” methods:

    
IHat sombrero = new Sombrero();
ListIterator hatIterator = hats.listIterator();
while (hatIterator.hasNext()) {
    IHat hat = hatIterator.next();
    if (hat.hasEarFlaps()) {
        hatIterator.remove();
        hatIterator.add(sombrero);
    }
}
    

With ListIterator, the remove and add method calls can be replaced with a single call to set:

    
IHat sombrero = new Sombrero();
ListIterator hatIterator = hats.listIterator();
while (hatIterator.hasNext()) {
    IHat hat = hatIterator.next();
    if (hat.hasEarFlaps()) {
        hatIterator.set(sombrero); // set instead of remove and add
    }
}
    

Use stream methods introduced in Java 8 With Java 8, programmers have the ability to transform a collection into a stream and filter that stream according to some criteria. Here is an example of how stream api could help us filter hats and avoid “ConcurrentModificationException”.

    
hats = hats.stream().filter((hat -> !hat.hasEarFlaps()))
        .collect(Collectors.toCollection(ArrayList::new));
    

The “Collectors.toCollection” method will create a new ArrayList with filtered hats. This can be a problem if the filtering condition were to be satisfied by a large number of items, resulting in a large ArrayList; thus, it should be use with care. Use List.removeIf method presented in Java 8 Another solution available in Java 8, and clearly the most concise, is the use of the “removeIf” method:

    
hats.removeIf(IHat::hasEarFlaps);
    

That’s it. Under the hood, it uses “Iterator.remove” to accomplish the behavior.

Use specialized collections

If at the very beginning we decided to use “CopyOnWriteArrayList” instead of “ArrayList”, then there would have been no problem at all, since “CopyOnWriteArrayList” provides modification methods (such as set, add, and remove) that don’t change the backing array of the collection, but rather create a new modified version of it. This allows iteration over the original version of the collection and modifications on it at the same time, without the risk of “ConcurrentModificationException”. The drawback of that collection is obvious - generation of a new collection with each modification.

There are other collections tuned for different cases, e.g. “CopyOnWriteSet” and “ConcurrentHashMap”.

Another possible mistake with concurrent collection modifications is to create a stream from a collection, and during the stream iteration, modify the backing collection. The general rule for streams is to avoid modification of the underlying collection during stream querying. The following example will show an incorrect way of handling a stream:

    
List filteredHats = hats.stream().peek(hat -> {
    if (hat.hasEarFlaps()) {
        hats.remove(hat);
    }
}).collect(Collectors.toCollection(ArrayList::new));
    

The method peek gathers all the elements and performs the provided action on each one of them. Here, the action is attempting to remove elements from the underlying list, which is erroneous. To avoid this, try some of the methods described above.

Common Mistake #9: Breaking Contracts

Sometimes, code that is provided by the standard library or by a third-party vendor relies on rules that should be obeyed in order to make things work. For example, it could be hashCode and equals contract that when followed, makes working guaranteed for a set of collections from the Java collection framework, and for other classes that use hashCode and equals methods. Disobeying contracts isn’t the kind of error that always leads to exceptions or breaks code compilation; it’s more tricky, because sometimes it changes application behavior without any sign of danger. Erroneous code could slip into production release and cause a whole bunch of undesired effects. This can include bad UI behavior, wrong data reports, poor application performance, data loss, and more. Fortunately, these disastrous bugs don’t happen very often. I already mentioned the hashCode and equals contract. It is used in collections that rely on hashing and comparing objects, like HashMap and HashSet. Simply put, the contract contains two rules:

If two objects are equal, then their hash codes should be equal.

If two objects have the same hash code, then they may or may not be equal.

Breaking the contract’s first rule leads to problems while attempting to retrieve objects from a hashmap. The second rule signifies that objects with the same hash code aren’t necessarily equal. Let us examine the effects of breaking the first rule:

    
public static class Boat {
    private String name;

    Boat(String name) {
        this.name = name;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        Boat boat = (Boat) o;

        return !(name != null ? !name.equals(boat.name) : boat.name != null);
    }

    @Override
    public int hashCode() {
        return (int) (Math.random() * 5000);
    }
}
    

As you can see, class Boat has overridden equals and hashCode methods. However, it has broken the contract, because hashCode returns random values for the same object every time it’s called. The following code will most likely not find a boat named “Enterprise” in the hashset, despite the fact that we added that kind of boat earlier:

    
public static void main(String[] args) {
    Set boats = new HashSet<>();
    boats.add(new Boat("Enterprise"));

    System.out.printf("We have a boat named 'Enterprise' : %b\n", boats.contains(new Boat("Enterprise")));
}
   

Another example of contract involves the finalize method. Here is a quote from the official java documentation describing its function:

The general contract of finalize is that it is invoked if and when the JavaTM virtual machine has determined that there is no longer any means by which this object can be accessed by any thread (that has not yet died), except as a result of an action taken by the finalization of some other object or class which is ready to be finalized. The finalize method may take any action, including making this object available again to other threads; the usual purpose of finalize, however, is to perform cleanup actions before the object is irrevocably discarded. For example, the finalize method for an object that represents an input/output connection might perform explicit I/O transactions to break the connection before the object is permanently discarded.

One could decide to use the finalize method for freeing resources like file handlers, but that would be a bad idea. This is because there’s no time guarantees on when finalize will be invoked, since it’s invoked during the garbage collection, and GC’s time is indeterminable.

Common Mistake #10: Using Raw Type Instead of a Parameterized One

Raw types, according to Java specifications, are types that are either not parametrized, or non-static members of class R that are not inherited from the superclass or superinterface of R. There were no alternatives to raw types until generic types were introduced in Java. It supports generic programming since version 1.5, and generics were undoubtedly a significant improvement. However, due to backward compatibility reasons, a pitfall has been left that could potentially break the type system. Let’s look at the following example:

    
List listOfNumbers = new ArrayList();
listOfNumbers.add(10);
listOfNumbers.add("Twenty");
listOfNumbers.forEach(n -> System.out.println((int) n * 2));
   

Here we have a list of numbers defined as a raw ArrayList. Since its type isn’t specified with type parameter, we can add any object into it. But in the last line we cast elements to int, double it, and print the doubled number to standard output. This code will compile without errors, but once running it will raise a runtime exception because we attempted to cast a string to an integer. Obviously, the type system is unable to help us write safe code if we hide necessary information from it. To fix the problem we need to specify the type of objects we’re going to store in the collection:

    
List listOfNumbers = new ArrayList<>();

listOfNumbers.add(10);
listOfNumbers.add("Twenty");

listOfNumbers.forEach(n -> System.out.println((int) n * 2));
The only difference from the original is the line defining the collection:

List listOfNumbers = new ArrayList<>();
   

The fixed code wouldn’t compile because we are trying to add a string into a collection that is expected to store integers only. The compiler will show an error and point at the line where we are trying to add the string “Twenty” to the list. It’s always a good idea to parametrize generic types. That way, the compiler is able to make all possible type checks, and the chances of runtime exceptions caused by type system inconsistencies are minimized.

Conclusion

Java as a platform simplifies many things in software development, relying both on sophisticated JVM and the language itself. However, its features, like removing manual memory management or decent OOP tools, don’t eliminate all the problems and issues a regular Java developer faces. As always, knowledge, practice and Java tutorials like this are the best means to avoid and address application errors - so know your libraries, read java, read JVM documentation, and write programs. Don’t forget about static code analyzers either, as they could point to the actual bugs and highlight potential bugs.

This article was originally published on Toptal

Sunday, April 20, 2014

SOLID design principle

When it comes to OO designing, it is a good idea to have a strategy to follow. A strategy allows you to think and organize ideas in a particular fashion that is comfortable to you. I’ve found SOLID principle easy enough for beginners and experts to understand and practice. This was originally put forward by Rober C. Martin, who is a pioneer in agile software development and extreme programming. Checkout Cleancoders to know more.

Chances are, you may be already using SOLID principle, just without giving it a name.

tl;dr

S - Single Responsibility Principle (SRP)

O - Open/Closed Principle (OCP)

L - Liskov Substitution Principle (LSP)

I - Interface Segregation Principle (ISP)

D - Dependency Inversion Principle (DIP)

Thats right, SOLID stands for a bunch of other acronyms.

Read on

S - Single Responsibility Principle (SRP)

The single responsibility principle states that every class should
have a single responsibility, and that responsibility should be
entirely encapsulated by the class. All its services should be
narrowly aligned with that responsibility.

Fairly simple. A Student class should manipulate Student properties and not the the properties of School. Specification of the class remains mostly untouched unless there is a big change in requirement of your software.

It is good to keep in mind that, there can be some exceptions to this. For example a utility class may provide methods for managing both Students and Schools.

O - Open/Closed Principle (OCP)

Software entities should be open for extension, but closed for modification.

The idea is that once a class is implemented completely, it should not be modified for including new features. Bugs and error correction must be done as and when required. Adding a new feature will require new specification and release of newer version.

http://en.wikipedia.org/wiki/Open/closed_principle

L - Liskov Substitution Principle (LSP)

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program. See also design by contract.

That right there is the basic use of Dependency Injection, right? You define a parent interface and replace them by concrete implementation which are derivatives.

class Animal {
    public void makeNoise() {
        System.out.println("noise");
    }
}

class Dog extends Animal {
    @override
    public void makeNoise() {
        bark();
    }

    public void bark() {
        System.out.println("bow bow bow");
    }
}

Dog dog = new Animal();
dog.makeNoise();

@Inject
Animal animal; // can be replaced by Dog

http://en.wikipedia.org/wiki/Liskov_substitution_principle

I - Interface Segregation Principle (ISP)

Many client-specific interfaces are better than one general-purpose interface.

Interfaces provide abstraction no implementation. When developing client interfaces, it should be kept at minimum and should only expose those methods which are essential for that client.

http://en.wikipedia.org/wiki/Interface_segregation_principle


interface Jumbable {
    void jump();
}

interface Climbable {
    void climb();
}

class Dog extends Animal implements Jumbable {
    @override
    void jump() {
        //jump
    }
}

class Monkey extends Animal implements Jumbable, Climbable {
    @override
    void jump() {
    }

    @override
    void climb() {
    }
}

D - Dependency Inversion Principle (DIP)

One should “Depend upon Abstractions. Do not depend upon concretions.”

Dependency injection is one method of following this principle.


interface JumpringService {
    public void jump();
}

public class JumpingServiceImpl implements JumpingService {

    @Inject
    private Jumpable jumbable;

    @override
    public void jump() {
        jumpable.jump();
    }
}

http://en.wikipedia.org/wiki/Dependency_inversion_principle

Sunday, April 6, 2014

map() function in JavaScript, Scala etc

These are absolutely awesome functions. They allow you to apply a function on every element of an array and return a new array with the result of the function.

In theory these are called higher-order functions, i.e they can take one or more function as an argument.

Consider the following JavaScript function:

var array = [1,2,3,4,5];
var twoTimesArray = array.map(function(n) {return n*2;});
console.log(twoTimesArray);

output: [2, 4, 6, 8, 10]

So that just multiplies every element of array by 2 and returns the resulting array.

Without map functions you would have done something like this:

var array = [1,2,3,4,5];
var twoTimesArray = [];
for(var i = 0; i < array.length; i++ ) {
    twoTimesArray[i] = array[i] * 2;
}
console.log(twoTimesArray);

Clearly, that is a lot of code compared to the previous one.

And, if you use Scala, code becomes much more concise.

scala> val l = List(1,2,3,4,5)
l: List[Int] = List(1, 2, 3, 4, 5)

scala> l.map(x => x*2)



Imagine doing the same thing in Java. First we will look at Java 6

List<Integer> array = Arrays.asList(1,2,3,4,5);
List<Integer> twoTimesArray = new ArrayList<Integer>();
for(Integer i: array) {
    twoTimesArray.add(i*2);
}



And in Java 8:

List<Integer> array = Arrays.asList(1,2,3,4,5);
List<Integer> twoTimesArray = new ArrayList<Integer>();
array.stream().forEach((string) -> {
    twoTimesArray.add(string*2);
});



The difference between for-each loop and using stream api (collection.stream()) in Java 8 is that we can easily implement parallelism when using the stream api with collection.parallelStream(). Whereas, in for-each loop you will have to handle threads on your own.

Programming becomes fun when we add bit of functional style into OO languages.

Sunday, March 30, 2014

Closures

Closures are a bit hard to understand concept for someone from an Object Oriented programming background, mainly because popular OO programming languages, (Java/C++) does not have this feature (As bjzaba pointed out in reddit, C++ 11 has Closures) haven’t embraced or promoted this feature until recently. It is more of a functional programming concept, although many Object Oriented languages has started to support Closures through first class functions or higher order functions.

I first heard about Closures while developing something in Javascript. If you have used the popular javascript library jQuery, you have already used closures, knowingly or unknowingly.

Here is my attempt to explain Closures, through examples in few programming languages. I will try to be as simple as possible.

From Wikipedia:

In programming languages, a closure (also lexical closure or function
closure) is a function or reference to a function together with a
referencing environment—a table storing a reference to each of the
non-local variables (also called free variables or up values) of that
function. A closure—unlike a plain function pointer—allows a
function to access those non-local variables even when invoked outside
its immediate lexical scope.

What that means:
1. Closure is a function (or a reference to a function)
2. You get a pointer to closure
3. So you can pass it around like an object
4. It knows about non-local variables
5. It can access those non-local variables, even when invoked outside of its scope
6. So we say, closures ‘closes’ on its environment
7. A function may create a closure and return it.

Few programming languages, that support Closures

  • Lisp
  • Javascript
  • Scala
  • Clojure
  • Ruby
  • Python
  • Haskell
  • PHP
  • Go

In closures procedure/method/function contexts become first-class. That means, with closures you can create functions that return functions, although that is only an outcome. An important point to understand here is, the closure methods refer to the context in which it was created, not to the one it was called.

To better understand closures one has to understand a variable’s scope, the best read about that would be understanding javascript variable scope.

Closures store references to the outer function’s variables; they do not store the actual value. So if we change the value of reference in closure it changes value outside of its scope.

You may implement closures using Anonymous functions, but all anonymous functions need not be a closure, although many of them are.

Why would anyone use Closures?

  • Reusability
  • Do more with less code
  • Make functional code stateful

Closures help us to write more expressive and concise code(once you get a hang of it!). We know objects have a state, using Closure we can give state to functions as well.

Now, let us take a look at examples of how to use closures in a few programming languages.

Examples

All of the following examples do the same thing: Create a closure to increment a number by another number.

1. Closure example in Javascript

This would be the easiest to understand code.

var incrementBy = function(x) {
    return function(y) {
        return x+y;
    };
};

// this will remember the value of 'x' forever
var incrementBy2 = incrementBy(2);
var incrementBy3 = incrementBy(3);

console.log(incrementBy2(4));
console.log(incrementBy3(8));
// Here you are creating a closure and calling it immediately
console.log(incrementBy(5)(8));

In the Javascript example above, we define a function incrementBy(x), which returns a function, that accepts parameter ‘y’ and returns sum of x and y. Here the value of ‘x’ will go into the closure of the returned function and will be accessible whenever the function is invoked.

Note that when calling incrementBy2(4) our closure remembers the value 2 (i.e ‘x’) that was passed earlier when doing var incrementBy2 = incrementBy(2);. And when invoking incrementBy2(4) we are actually passing the value of y as 4. Hence the statement return x+y will transform to return 2+4. Cool right!!?

2. Closure example in Scala

object Closure {

    // define the closure using one line of code, power of Scala
    def incrementBy(x:Int) = (y:Int) => x + y        

    def main(args: Array[String]) = {

        var incrementBy3 = incrementBy(3)
        val incrementBy5 = incrementBy(5)

        println(incrementBy3(5))
        println(incrementBy5(10))
        println(incrementBy(20)(20))    
    }    
}

The example in Scala is similar to the example in Javascript except for Scala’s awesome one liner syntax.

3. Closure example in Lisp (Clisp)

(defun increment(y)
    (defun incrementBy(x)
        (+ y x)
    )
)

(increment 4)
(incrementBy 5) ; 9
(incrementBy 10) ; 14

There are several ways of doing this is lisp. This is only one way of doing it. Here you are not getting a pointer to the closure function and will probably make it useless. See this link to see how to return functions is Clisp.

4. Closure example in Clojure

(def increment (fn [y] 
    (def incrementBy (fn [x]
      (+ x y)
      ))
))

(increment 4)
(incrementBy 5) ; 9
(incrementBy 10) ; 14

As you can see, the syntax of clojure and lisp are extremely similar.

5. Closure example in Python

def incrementBy(x):
    def increment(y):
        return x+y
    return increment

incrementBy4 = incrementBy(4)
incrementBy6 = incrementBy(6)

print incrementBy4(5)  # 9
print incrementBy6(10) # 16

The above example in Python is pretty similar to the one in Javascript and is easy to understand. Here we define the closure function increment(y) and then return it. Just remember to take care of the tabs!

6. Closure example in Ruby

class Closure

  # Ruby example using Proc.new
  def incrementBy(x)
    return Proc.new {|y| x+y }
  end

  # Ruby example using lambda
  def incrementByLambda(x)
    lambda {|y| x+y}
  end

end

closure = Closure.new
increment5 = closure.incrementBy(5)
incrementByLambda7 = closure.incrementByLambda(7)

puts increment5.call(6)
puts incrementByLambda7.call(6)

Ruby can do this is in two ways, using Proc and using lambda. The lambda functions in Ruby are similar to lambda’s in lisp.


So that was examples about closures. Hope that gives you at least some idea about Closures. If you know how do the same in any other languages, please feel free to share. Also checkout the references, they are good reads.

References:

Thanks to Craig for sharing Go snippet

Reddit thread here: http://redd.it/223b7p

Tuesday, March 18, 2014

PostgreSQL 9.3 initial setup on Mac OSX 10.9.2

After sudo port install postgresql93 postgresql93-server


# switch to su
sudo su

mkdir /var/lib/pgsql/

chown -R postgres:wheel /var/lib/pgsql

su postgres

export PGDATA=/var/lib/pgsql/9.3/data

initdb

createdb pgdbname

createuser -A -D pgusername

exit

exit

# startdb
sudo -u postgres postgres -D /var/lib/pgsql/9.3/data/

# check if login works
psql -h localhost pgdbname pgusername

\q

# add PGDATA to ~/.bash_profile
echo "export PGDATA=/var/lib/pgsql/9.3/data" >> ~/.bash_profile

Related Posts Plugin for WordPress, Blogger...