Best Strategy ? Abstract classess Or Interface

Few points before to proceed :

1) Abstract class can have one or more abstract methods as well as concrete methods.
2) An abstract class can't not be instantiated.
3) To use functionality of abstract class One can create a concrete class that has to instantiate the abstract class and must have implementation for each abstract method.
4) Abstract classes are usually declared where two or more subclasses are expected to fulfill a similar role in different ways through different implementations.
5) Interfaces defines the behavior of the classes. in another word Contract.
6) All methods declared in interface are abstract by default, no need to use abstract keyword.
7) Basic feature of OO is Encapsulation : Reveal an object's programming interface (functionality of the object) without revealing its implementation.
8) Interfaces have no direct inherited relationship with any particular class, they are defined independently. Interfaces themselves have inheritance relationship
among themselves.

When Should Interfaces or Abstract classes some point are below :
First and very important is "Choice of design".
Second there are some facts and features of each, according to design we should use them.

1) Using Interfaces, The implementation can change without affecting
the caller of the interface.
2) Using Interfaces, Unrelated (One class is not a sub-class of another class) classes can implement similar methods(behaviors).
3) An interface can only define constants while abstract class can have fields.
4) Use Abstract classes, where you want to provide common implementation code for all its sub classes. It reduces the duplication. However we should not forget that a concrete can extend only one super class whether that super class is in the form of concrete class or abstract class.

I would use interfaces when I think that something there are very frequent changes in my design. How??? Simple example :

Consider an interface that you have developed called "TaskHandler":

public interface TaskHandler{
void performSomething(int i, float x);
int performMore(String s);
}

Now after some time , you want to add a third method to "TaskHandler", so that the interface now becomes:

public interface TaskHandler{
void performSomething(int i, float x);
int performMore(String s);
boolean willYouPerform(int i, float x, String s);
}

Points to be noted:

If you make this change, all classes that implement the old TaskHandler
interface will break because they don't implement all methods of
the the interface now.

Solution :
Create one more interface OtherTaskHandler that extends TaskHandler interface

public interface OtherTaskHandler extends TaskHandler {
boolean willYouPerform(int i, float x, String s);
}

Now Its up to users, he/she can choose to continue to use the old interface or to upgrade to the new interface.

Java is not a Pure Object Oriented Language

Theoretical a Pure Object Oriented Language must contains all entities as in the form of Object. There could be two categories of OOPL :
1) Hybrid OO languages :
Hybrid languages are based on some non-OO model that has been enhanced with OO concepts. e.g. C++, ancestor was C, may be more...

2) Pure OO languages
Pure OO languages are based entirely on OO principles; Smalltalk, Java, and Simula are pure OO languages.

But Due to following reasons Java can't be considered as Pure OOPL:
1) Java violates principle "Everything must be Object". Java has primitive types int, long etc.
2) static works on class level.
3) Multiple inheritance is not supported.
4) Operator overloading is not supported.

BTW Java never claimed to be "Pure OOPL".

Refactoring of Code

Refactoring is basically a continuous job for a software programmer to improve code quality and maintainability.
Some good software programmer used to do this with / without knowing of it e.g. moving methods to the super class / abstract class, making general function to do more stuff in small code etc. Generally there will not be extra time given for refactoring the code, unless the code is not able to use without doing it. Whenever a new feature or bug arrives refactoring should be done to improve quality,maintainability and extendability of code.

Software developers are often not willing to do refactoring, because some refactoring are simply tedious and also there is no visible external benefit for all the efforts put in.

It is very common that management only emphasis / rewards externally visible code like new feature and enhanced performance etc but very much not interested to code's quality. However after the code reviews if software developers want to spend some time to refactoring the code, there could be some risk of breaking code via refactoring operations e.g. code is not written as per the coding standards etc.

A software developer wants to refactor some poorly written / structured code, their lead or manager would have a different vision altogether on it and its very common that he /she may deny to modify the working / deployed code. These things also can't be ignored. Sometimes developer and management take decision together of refactoring of bad code.