Rule 8:Refer to objects by their interfaces
If appropriate interface types exist, then parameters, return values, variables, and fields should all be declared using interface types.
The only time you really need to refer to an object’s class is when you’re creating it with a constructor.
To make this concrete, consider the case of LinkedHashSet, which is an implementation of the Set interface. Get in the habit of typing this:
// Good – uses interface as type Set sonSet = new LinkedHashSet<>();
If you get into the habit of using interfaces as types, your program will be much more flexible. If you decide that you want to switch implementations, all you have to do is change the class name in the constructor(or use a different static factory). For example, the first declaration could be changed to read: Set sonSet = new HashSet<>();
There is one caveat: if the original implementation offered some special functionality not required by the general contract of the interface and the code depended on that functionality, then it is critical that the new implementation provide the same functionality. For example, if the code surrounding the first declaration depended on LinkedHashSet’s ordering policy, then it would be incorrect to substitute HashSet for LinkedHashSet in the declaration, because HashSet makes no guarantee concerning iteration order.
So why would you want to change an implementation type? Because the second implementation offers better performance than the original, or because it offers desirable functionality that the original implementation lacks. For example, suppose a field contains a HashMap instance. Changing it to an EnumMap will provide better performance and iteration order consistent with the natural order of the keys, but you can only use an EnumMap if the key type is an enum type.
It is entirely appropriate to refer to an object by a class rather than an interface if no appropriate interface exists.
For example, consider value
classes, such as String and BigInteger. Value classes are rarely written with multiple implementations in mind. They are often final and rarely have corresponding interfaces. It is perfectly appropriate to use such a value class as a parameter, variable, field, or return type.
If there is no appropriate interface, just use the least specific class in the class hierarchy that provides the required functionality.
Rule:prefer interface to reflectoin
Disadvantages
• You lose all the benefits of compile-time type checking,
Performance suffers
Techglot 