Friday, January 9, 2015

Abstract class

Abstract classes in Java are classes which cannot be instantiated, meaning you cannot create new instances of an abstract class. The purpose of an abstract class is to function as a base for subclasses.

The only time a subclass of an abstract class is not forced to implement all abstract methods of its superclass, is if the subclass is also an abstract class.

Abstract Methods

An abstract class can have abstract methods. You declare a method abstract by adding the abstract keyword in front of the method declaration. Here is how that looks:
An abstract method has no implementation. It just has a method signature.
If a class has an abstract method, the whole class must be declared abstract. Not all methods have to be abstract, even if the class is abstract. An abstract class can have a mixture of abstract and non-abstract methods.

The Purpose of Abstract Classes

The purpose of abstract classes is to function as base classes which can be extended by subclasses to create a full implementation. For instance, imagine that a certain process requires 3 steps:

The step before the action.
The action.
The step after the action.
If the steps before and after the action are always the same, the 3-step process could be implemented in an abstract superclass like this:

public abstract class MyAbstractProcess {

    public void process() {
        stepBefore();
        action();
        stepAfter();
    }

    public void stepBefore() {
        //implementation directly in abstract superclass
    }

    public abstract void action(); // implemented by subclasses

    public void stepAfter() {
        //implementation directly in abstract superclass
    }
}
Notice how the action() method is abstract. Subclasses of MyAbstractProcess can now extend MyAbstractProcess and just override the action() method.

When the process() method of the subclass is called, the full process is executed, including the action() method of the subclass.

Of course, the MyAbstractProcess did not have to be an abstract class to function as a base class. Nor did the action() method have to be abstract either. You could have just used an ordinary class. However, by making the method to implement abstract, and thus the class too, you signal clearly to the programmer, that this class should not be used as it is, but be used as a base class for a subclass, and that the abstract method should be implemented in the subclass.

Static

Static means that can be access in an static way (that not need to instanced the class like new ExampleClass)
You can treat static as a global variable which has scope. It basically means if you change it for one object it will be changed for all just like a global variable(limited by scope).

Methods
Java static method program: static methods in Java can be called without creating an object of class. Have you noticed why we write static keyword when defining main it's because program execution begins from main and no object has been created yet. Consider the example below to improve your understanding of static methods.

http://www.programmingsimplified.com/java/source-code/java-static-method-program


Sunday, December 21, 2014

Java static class

In this example, we will discuss about static classes in Java. First of all, let’s give a short explanation of the static modifier. For example, if a field or a method in a class has the static modifier in its declaration , then it is always associated with the class as a whole, rather than with any object of the class.

In the code below we have declared a class named Vehicle, a class field member named vehicleType and a method named getVehicleType(), both declared as static.

ONLY nested classes can be static

The main difference is that inner class requires instantiation of the outer class so as to be initialized and it is always associated with an instance of the enclosing class. On the other hand nested static class is not associated with any instance of the enclosing class. Nested static classes are declared with the static keyword, which means than can be accessed like any other static member of class, as we shown before.

http://stackoverflow.com/questions/7486012/static-classes-in-java

Why should I use the keyword “final” on a method parameter in Java?

Sometimes its nice to be explicit(for readability) that the variable doesn't change. Here's a simple example where using final can save some possible headaches

public void setTest(String test) {
    test = test;
}
if you forget the 'this' keyword on a setter the variable you want to set doesn't get set. However if you used the final keyword on the parameter then the bug would be caught at compile time.

http://stackoverflow.com/questions/500508/why-should-i-use-the-keyword-final-on-a-method-parameter-in-java

Difference Between String , StringBuilder and StringBuffer Classes

String

String is immutable  ( once created can not be changed )object  . The object created as a String is stored in the  Constant String Pool  .
Every immutable object in Java is thread safe ,that implies String is also thread safe . String can not be used by two threads simultaneously.
String  once assigned can not be changed .

String  demo = " hello " ;
// The above object is stored in constant string pool and its value can not be modified.


demo="Bye" ;     //new "Bye" string is created in constant pool and referenced by the demo variable          
 // "hello" string still exists in string constant pool and its value is not overrided but we lost reference to the  "hello"string

StringBuffer

StringBuffer is mutable means one can change the value of the object . The object created through StringBuffer is stored in the heap .  StringBuffer  has the same methods as the StringBuilder , but each method in StringBuffer is synchronized that is StringBuffer is thread safe .

Due to this it does not allow  two threads to simultaneously access the same method . Each method can be accessed by one thread at a time .

But being thread safe has disadvantages too as the performance of the StringBuffer hits due to thread safe property . Thus  StringBuilder is faster than the StringBuffer when calling the same methods of each class.

StringBuffer value can be changed , it means it can be assigned to the new value . Nowadays its a most common interview question ,the differences between the above classes .
String Buffer can be converted to the string by using
toString() method.

StringBuffer demo1 = new StringBuffer("Hello") ;
// The above object stored in heap and its value can be changed .
demo1=new StringBuffer("Bye");
// Above statement is right as it modifies the value which is allowed in the StringBuffer

StringBuilder

StringBuilder  is same as the StringBuffer , that is it stores the object in heap and it can also be modified . The main difference between the StringBuffer and StringBuilder is that StringBuilder is also not thread safe.
StringBuilder is fast as it is not thread safe .


StringBuilder demo2= new StringBuilder("Hello");
// The above object too is stored in the heap and its value can be modified
demo2=new StringBuilder("Bye");
// Above statement is right as it modifies the value which is allowed in the StringBuilder


http://javahungry.blogspot.com/2013/06/difference-between-string-stringbuilder.html

Saturday, December 20, 2014

String pool

As the name suggests, String Pool is a pool of Strings stored in Java Heap Memory. We know that String is special class in java and we can create String object using new operator as well as providing values in double quotes. Here is a diagram which clearly explains how String Pool is maintained in java heap space and what happens when we use different ways to create Strings.


String Pool is possible only because String is immutable in Java and it’s implementation of String interning concept. String pool is also example of Flyweight design pattern.

Object, classes, reference

If you like housing metaphors:

a class is like the blueprint for a house. Using this blueprint, you can build as many houses as you like.
each house you build (or instantiate, in OO lingo) is an object, also known as an instance.
each house also has an address, of course. If you want to tell someone where the house is, you give them a card with the address written on it. That card is the object's reference.
If you want to visit the house, you look at the address written on the card. This is called dereferencing.
You can copy that reference as much as you like, but there's just one house -- you're just copying the card that has the address on it, not the house itself. Java methods are always pass-by-value, but the value could be an object's reference. So, if I have:

Foo myFoo = new Foo();     // 1
callBar(myFoo);            // 2
myFoo.doSomething()        // 4

void callBar(Foo foo) {
    foo = new Foo();       // 3
}
Then let's see what's happening.

Several things are happening in line 1. new Foo() tells the JVM to build a new house using the Foo blueprint. The JVM does so, and returns a reference to the house. You then copy this reference to myFoo. This is basically like asking a contractor to build you a house. He does, then tells you the house's address; you write this address down.
In line 2, you give this address to another method, callBar. Let's jump to that method next.
Here, we have a reference Foo foo. Java is pass-by-value, so the foo in callBar is a copy of the myFoo reference. Think of it like giving callBar its very own card with the house's address on it. What does callBar do with this card? It asks for a new house to be built, and then uses the card you gave it to write that new house's address. Note that callBar now can't get to the first house (the one we built in line 1), but that house is unchanged by the fact that a card that used to have its address on it, now has some other house's address on it.
Back in the first method, we dereference myFoo to call a method on it (doSomething()). This is like looking at the card, going to the house whose address is on the card, and then doing something in that house. Note that our card with myFoo's address is unchanged by the callBar method -- remember, we gave callBar a copy of our reference.
The whole sequence would be something like:

Ask JVM to build a house. It does, and gives us the address. We copy this address to a card named myFoo.
We invoke callBar. Before we do, we copy the address written on myfoo to a new card, which we give to callBar. It calls that card foo.
callBar asks the JVM for another house. It creates it, and returns the new house's address. callBar copies this address to the card we gave it.
Back in the first method, we look at our original, unchanged card; go to the house whose address is on our card; and do something there.

http://stackoverflow.com/questions/9224517/what-is-a-class-reference-and-an-object