Java pattern for future type change

Question

What is the best way to program against an anticipated type change. Say, I may have to use Joda DateTime instead of Java Date in the future. Since Java doesn't encourage anti pattern like typedef, what is the best way to ensure an easy refactoring in the future.
thanks.

Answer 1

Certainly the "Single Responsibility Principle" or something near it and encapsulation should help limit dependency creep.

However, choice of basic types is an architectural decision. If you were to change string or integer types, you'd expect change across your code. Date isn't that much different.

Answer 2

Programming to interfaces and proper layering is the best defensive measure I can think of.

When you separate what is done from how it's done, you leave yourself the possibility of changing implementations without affecting clients as long as the interface is unchanged.

If you have to change the interface, or if you end up doing a new problem altogether, all bets are off. No language has built-in clairvoyance.