Java pattern for changing the future type

Question

What is the best way to program against an expected type change. Let's say I might have to use Joda DateTime instead of Java Date in the future. Since Java does not encourage an anti-pattern like typedef, the best way to provide easy refactoring in the future.
thanks.

Answer 1

Of course, the “principle of single responsibility” or something alongside it and encapsulation should help limit the creep of addiction.

However, the choice of the main types is an architectural solution. If you want to change string or integer types, you can expect a change in your code. The date is not that different.

Answer 2

Interface programming and proper layering is the best defensive measure I can think of.

When you separate what is being done from how it is done, you leave yourself the ability to change implementations without affecting clients, until the interface changes.

If you need to change the interface, or if you end up with a new problem, all bets are disabled. No language has built-in clairvoyance.

Answer 3

Wrap the API / type in question behind the wrapper interface and use it only through the shell. Then you only need to change the shell code to switch the implementation.

This will be a common solution. However, Tom is right in pointing out that the date is so fundamental that her choice should be an architectural decision that should not change frequently.

Answer 4

Sounds to me as if you want to perform “dynamic reclassification”,
I think you can achieve this with the State pattern .
Please view an example here: http://cnx.org/content/m17225/latest/

Answer 5

You can try eclipse IAdaptable

Answer 6

What is the best way to program? against the expected type change.

Keeping your design as simple and clean as possible while maintaining a good set of unit tests.

This will help you with all future changes, including unforeseen ones (which is much more common).

Answer 7

I believe that a good Java IDE can significantly reduce the pain of large-scale data type changes. You are looking for points at which your code uses the old class, are replaced by the new class, and correct subsequent compilation errors and repeat. When you are done with the changes, run the unit / regression tests, correct the errors and (touch the tree!), You are done.

OK ... it might not be that simple. In particular:

• Reflective dependencies can be difficult to find.
• Difficulties in the external connection / configuration file can be difficult to find.
• A large-scale application consisting of components written or supported by many people can be problematic. (You cannot just hack all elses codes.)