Imagine if you will, a past in which object-orientation and reuse had become the way we developed software, rather than the chaotic not-invented-here hackery that was the best we were able to create back then. (And I was there back then, and we were doing our best.)
In this alternate history, the object library (there is of course only one) contains a Date object which happens to support only 2-digit years. (Even if our practices were perfect, somehow we came up with this 2-digit date thing.)
Our input/output formats are all in the library also, and of course all the date ones are part of the date class. Record-level I/O formats are collections of formats for various objects, recursively down until you find the Date formats (which probably recursively use Integer and String formats).
Of course your own programs use these objects, and equally of course all your commercial software, databases and so on, also use these same objects. Industry-wide reuse. BradCox is President of the World, did I mention that?
One day someone notices, amid all this glory, that the year 2000 is coming, and the response to this discovery is that we need to do something about the 2-digit year thing.
We go to the Date class, and enhance it to 4-digit date computation. We change the IO formats to read and write 4-digit dates.
We run our tests. All the programs that use dates internally, or that create new files and subsequently read them, work. They have all inherited the new Date class and the new Date I/O. But the programs that read old files don't work: the old files have two-digit dates in them.
We modify the Date I/O routines to accept the old 2-digit input format and the new 4-digit format. We run the tests again. Now all the tests run. We release the new Date class to the library and go home early.
From this slightly(!) idealized story we can now see that the Y2K problem was caused by poor factoring and lack of reuse, not by application of YouArentGonnaNeedIt. --RonJeffries
See Also: YtwokSecondaryEffects
I think that AspectOrientedProgramming tries to make knobs of things that are not normally seen in code. I also think that refactoring is making finer knobs out of coarser knobs and introducing new knobs. Some systems don't have a knob for date, simply because nobody ever thought date should be a knob. I think that the profound thing is that in object oriented programming, we pick our coarse knobs when we pick our metaphors. The WholeSortOfGeneralMishMash can be sliced many ways.
This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004