CS527

In Refactoring to Patterns (pg. 13), Josh mentions that while looking over code before a workshop, he saw code that read:

november(20, 2005)

And called a method that looked like:

public void Date november(int day, int year)

Josh likes this code much better than just using the corresponding 3 lines of java to produce a date directly in the code, since the date reads like spoken language and separates important code from distracting code.

So I read this during a vacation, while my wife was driving the car, and after my son read that portion of the book, I was discussing this concept with my son. My wife said, “why do all the dates need to be in November?” I said, they don’t. There would be 12 different methods. My wife said that sounded silly. Which left me scrambling to figure out why this sounded good.

I said, well for international applications, since some places use a month/day/year format, some use a day/month/year format, and some use a year/month/day format then this type of approach would make it easier for people to know which format was being used. And no sooner had I made that argument than I realized its flaw, which my wife realized and pounced on. “But foreign countries would have different names for the months anyway, which would make the code extra confusing. Why not just have one method that lets you specify the month, day and year.”

So for almost two weeks, I’ve been thinking about this issue, and I’m still not sure if saying

november(20, 2005)

is good or bad. Or better than something like

makeDate(11, 20, 2005)

What do other people think?