Friday 22 November 2013

Java Tip: Do not attempt to call a method in a superclass once it has been overridden

Well, it is impossible to call a method in superclass once it has been overridden in the subclass. Well, little things like these are basics of Java and OOP but it is not very unusual to forget them and see some pretty amusing results. I will illustrate the same with an example:

Consider the following classes Mock, MockSubClass and MockerMain.

As the name goes, MockSubClass inherits from the parent class Mock and MockerMain is the class bearing my main method.

The class definitions have been given below:
package mocker;

import java.util.Collection;
import java.util.Set;

MOCK
public class Mock {

Set s;

protected Mock (Set newSet) {
s = newSet;
}

protected void addMethod (Object o) {
s.add(o);
}

protected void addMethodAll (Collection c) {

System.out.println("Inside method addMethodAll\n");

for ( Object o: c ) {
addMethod (o);
}
}

protected Collection getCollection () {
return s;
}
} //end class Mock

MOCKSUBCLASS

package mocker;

import java.util.Collection;
import java.util.Set;


public class MockSubClass extends Mock{

/**
*/
int addCount;
public MockSubClass (Set c) {
// TODO Auto-generated constructor stub
super (c);
addCount = 0;
}
public void addMethod (Object o) {
System.out.println("Inside MockSubClass.addMethod\n");
addCount++;
super.addMethod(o);
}
public void addMethodAll (Collection c) {
int size = c.size();
addCount = addCount + size;
super.addMethodAll(c);
}
public int getAddCount () {
return addCount;
}
public Collection getCollection () {
return super.getCollection();
}

}//end class MockSubClass

MOCKERMAIN

package mocker;
import java.util.Arrays;
import java.util.HashSet;
import java.util.Set;

public class MockerMain {

/**
* @param args
*/
public static void main(String[] args) {
// TODO Auto-generated method stub
int count = 0;
Set <String> s = new HashSet <String> ();
MockSubClass Obj = new MockSubClass (s);
Obj.addMethod("LV");
count = Obj.getAddCount();
System.out.printf("1.)"+"count = "+count+"\n");
Obj.addMethodAll(Arrays.asList("LA","Sacramento","SF"));
count = Obj.getAddCount();
System.out.printf("2.)"+"count = "+count+"\n");
System.out.printf("3.)"+"List = "+Obj.getCollection()+"\n");
}

}//end class MockerMain

Well, what I am looking to do here is to create a collection and add some random strings to the collection and use the method getAddCount() in MockSubClass to retrieve the value of number of elements in the collection currently. I inserted one element first and then the addCount got updated accordingly in MockSubClass. Now, I am adding three more elements and the 3 is being added to the current value of addCount which is 1. Well, that's what the code appears to be doing. But, here is where we need to understand that addMethodAll in MockSubClass makes a call to addMethodAll in the superclass, Mock. On careful examination of the method, addMethodAll in Mock, we can see that it in turn makes a call to addMethod one time each for each element of the collection which is being added. The method, addMethod has been overridden by the subclass, so the call is actually serviced by the version in the subclass and not by the one in the superclass itself. This therefore leads to addition by another 3 and the value of addCount at this point is 7 and not 4 as required.

Output:
Inside MockSubClass.addMethod

1.)count = 1
Inside method addMethodAll

Inside MockSubClass.addMethod

Inside MockSubClass.addMethod

Inside MockSubClass.addMethod

2.)count = 7
3.)List = [LA, LV, SF, Sacramento]


Thursday 21 November 2013

Understanding the impact of Encapsulation in Programming

I have been learning about OOP principles for a long time now and Encapsulation or Data Hiding interested me most. This is because, at the face of it, it sounds and appears most simple. But, for a fact, I always knew given my little practical experience that I understood very little about it and as to why it even mattered. 
I had been reading all along about it in different books on Java and thereafter online. Some of them helped me attain an insight while the others were more like text book material. I finally happened to read "Effective Java" by Joshua Bloch and I can see things getting better already.
The most interesting idea underlying the declaration of data member variables of a class as "Private" or in a more relaxed environment, "Default" (commonly referred to as Package-Private) is to mitigate effects due to coupling between different modules of a program or the application itself in a broader sense. Such a careful design ensures that the different modules are developed, tested and maintained as independently from one another as possible. This ensures that any holes or bugs present in one module do not seriously impair another module and thus preventing the effects of one or two holes in one or two isolated modules from hampering the entire system itself. This is in keeping with maintainability, of course.
Just to give you a simple example, consider the following classes, Square and AreaOfSquare:
class Square {
public int side;
}// end of class Square

class AreaOfSquare {
private int area;
public int getArea (Square s) {
area = s.side*s.side;
return area;
}
}// end of class AreaOfSquare
Well, while it is a rather funny thing to declare "side" as "int", it is still a possibility especially if the designer never anticipated the need for a more precise definition of this parameter. Now, say tomorrow. this designer felt like going back on his design and getting the declaration changed to "double" instead, he would have to also change the declaration of "area" inside the AreaOfSquare class to "double". It is reasonably simple for such one-one dependency between two classes, but if we had a few more classes that were dependent on Square, it would be a fairly complex undertaking from the testing and maintenance perspective. In fact, it would even be reasonable to make an assumption that the designer would himself be unable to recollect all such dependencies and do the repairs accordingly.

Friday 15 November 2013

Revival of the Functional Programming Paradigm

I have been programming for some years now and I started with C++ (unusual because C is the most general starter) back in school. Then as I moved to high school and later on, undergrad, I learnt a little more of C++ and then it was Java all along. It should be about 6 years since I started programming in Java (on an academic level, that is) and all this is only to say that Imperative Programming which is pretty intuitive and easy to learn has become quite popular today.
Somewhere in my final year of undergrad, I was exposed to Lisp and I never quite got the head or tail of it for it seemed to work rather differently. Luckily for me, then, it was just an introduction and confined to a few basic programming examples and I didn't have to worry about learning the same from a test perspective. Then, last year, my professor remarked rather casually that Functional Programming which is a rather old paradigm has now a future and that it would be a great idea for passionate programmers to revisit it. 
I did start exploring Scala (a functional programming language) and my initial exploration was largely confined to a handful of web links that didn't really get the crux of the idea of Functional Programming across to me. Then, I happen to stumble upon this great YouTube video in which leading scientist, Martin Odersky speaks about Functional Programming at the O'Reilly OSCON Java 2011 conference. I have linked the video below and like I always do, provided a brief explanation regarding the same a little later, down below.



One of the biggest challenges faced by programmers these days is Non-Determinism. Now, consider a program having the following block of code below:
x = x + 1;
x = x / 2;
Say, you have two threads running in the same program. What is deterministic here is that each thread runs the above block of code in programmatic order from top to bottom within itself. But, what is non-deterministic, however, is the order in which these two lines of code execute in the two threads with respect to each other. Let me provide an example here to make things a little more clearer: 
One possible execution context, A:
Thread 1: x = x + 1
Thread 2: x = x + 1
Thread 2: x = x / 2
Thread 1: x = x / 2
Another valid execution context, B:
Thread 1: x = x + 1
Thread 1: x = x / 2
Thread 2: x = x + 1
Thread 2: x = x / 2
There is in fact, a few more possible execution execution contexts. But, what's clear is that in multi-threaded programs, the sequence of execution of instructions with respect to Time as a dimension is not certain or deterministic  given that it is entirely in the operating system's discretion to schedule and dispatch threads for execution. While memory models such as JMM guarantee top-down order of execution within each thread, there are really no guarantees regarding the interleaving of these instructions with respect to different concurrent threads as can be seen from the above example.
This Non-Determinism is a result of two widely seen aspects of modern day programs:
a. Parallelism , b. Variable/Reference Mutability
We have already seen pretty clearly as to how Parallelism can lead to uncertainty or Non-Determinism. What we need to see now is the role of Variable/Reference Mutability to bring about the same effect.
Taking a deeper look at the above example, we can see that, x is a variable and its value is being mutated in the program. Now, if x is a thread-local variable, there is really no reason to worry for the programming language memory model ensures that the instruction execution sequence is strictly the program order. But, that's only as far as x is thread-local. If x is a global variable (for the two threads), the final value of x depends on the complete execution sequence. 
Let's consider contexts A and B now:
If the initial value of x is 1, execution context A would give final value, 0.75 whereas B would result in final value, 1 for x.
This is because the value of x computed at each stage is dependent on the value of x from the previous stage. We can now quite clearly see as to how Variable/Reference Mutability can play its part in rendering the result of the program, non-deterministic.
Here is where Functional Programming comes to the rescue with its varied emphasis upon looking at the problem from the perspective of Space as against Time. This different approach now accomplishes Parallelism and better resource utilization, but differently. Here, a task is divided into units that can be independently worked on by multiple execution units working in parallel. That is, execution unit works on a specific task unit and its execution scope is outside the scope of execution of other execution units. This is in contrast to division of task into sub-units that are worked upon by execution units in a pipeline fashion one after the other. While such pipelined execution is faster than the simplistic one sub-unit at a time execution, it is definitely not parallelism in the true sense. 
So, we have now seen as to how Functional Programming aids Parallelism by knocking off the impact of aspect b, which is Variable/Reference Mutability. Languages such as Scala have given Functional Programming a whole new face by combining its benefits with those of OOP and modern day trends such as Agile Development. This is sufficient to see that solutions to needs of the future largely lie across a multitude of individual candidate solutions.







Wednesday 6 November 2013

Understanding Factory Methods

I have myself been using factory methods for a while now and it would be factually incorrect to tell you that I never cared to understand why I used them as against plain constructor "new" method of object instantiation. Nevertheless, I must definitely admit that I would have read about them several times but wasn't really fortunate to remember all these benefits clearly. This called on me to write a post regarding the same so that it would get entrenched in my head thereafter.

Now, let's quickly get started:


  • The use of getInstance() or valueOf() in a factory design pattern helps you to procure a reference to an object of a type without having to explicitly worry about the sub-type of the object returned. Hazy? It surely would be no better with an explanation of this sort. Now, let me dig deeper.
Consider an interface, "Car" which is implemented by "Mazda" and "Sedan". Now, it is fairly clear that both of these are cars themselves and as such, one can do with a reference to an object of either Mazda or Sedan when one needs to procure a reference to an object of Car type. So, it's fairly clear that the application of a framework such as Spring in Java that relies on Dependency Injection (which can be understood more simply as some form of Late Binding or Run-time Binding ) can exploit this compile-time abstraction and as such benefit from the same.

  • Among other benefits, what interests me most is an idea based upon an extension to the factory pattern which limits the number of objects of a class to one. Such a class is called a Singleton and it is typically a means to reuse existing class objects where possible rather than creating new ones. Thus, it is not difficult to understand that this is in keeping with memory efficiency.