MyCalendar subclass and threading

[VisionSet]

I have an application that deals with alot of dates, I have classes that
represent time & duration. I do not need to cart around the beast that is
GregorianCalendar.
However I do need to use it to convert data.

eg:
gregCal.setTime(myDate);
gregCal.get(Calendar.DATE);
gregCal.get(Calendar.MONTH_OF_YEAR); // etc

Also I really need a different Calendar, something that I can do this with

myCal.isSpecialDay();

So I'm wondering whether I should subclass Calendar/Gregorian to add my
special dates.

Because I don't see the need to have an instance of this in my time/duration
objects, I'm thinking, I could have a Singleton MyCalendar to use for look
ups.

At present there isn't a threading issue, just one thread. But I'd like to
make it thread safe, none the less. Also if there are multiple threads
eventually, I should convert my Singleton to an Object pool - right?

Anyhow I'd need to synchronise over several calls within MyCalendar to make
sure the date is setup and retrieved correctly:

synchronized public boolean isSpecialDay(Date date) {
setTime(date);
return isSpecialDay();
}
Presumably I should make all methods that set the date synchronized also?

I know there is probably some bad stuff above, how should I do this please?

 

[Anthony Borla]

I have an application that deals with alot of dates, I
have classes that represent time & duration. I do not
need to cart around the beast that is GregorianCalendar.
However I do need to use it to convert data.

eg:
gregCal.setTime(myDate);
gregCal.get(Calendar.DATE);
gregCal.get(Calendar.MONTH_OF_YEAR); // etc

Also I really need a different Calendar, something that I
can do this with

myCal.isSpecialDay();

So I'm wondering whether I should subclass Calendar/Gregorian
to add my special dates.

If your class only needs to make publically available only a subset of
'GregorianCalenadar's functionality, then why create a subtype, thus
exposing its interface to the world ? Better, perhaps, to wrap it up and
create your own interface, one better suited to your needs. If subtyping is
needed for some reason, just subtype via a private inner class and wrap up
the overridden method(s).

Also, it doesn't sound as if you will want to further subtype your class, so
another reason for not using inheritance exists

Because I don't see the need to have an instance of this in my
time/duration objects, I'm thinking, I could have a Singleton
MyCalendar to use for look ups.

Sounds pretty good so far. As a general rule, avoiding numerous object
instantiations is certainly in the interests of efficiency. However, only
comparison testing will verify whether it makes much of a difference in
specific applications [a re-statement of the rather obvious ].

At present there isn't a threading issue, just one thread.
But I'd like to make it thread safe, none the less.
Also if there are multiple threads eventually, I should
convert my Singleton to an Object pool - right?

It probably depends on how heavily you expect this object to be used. Put
simply, if all 'critical' methods are synchronised, and only 'low volume'
[not a very precise measure, I know] usage is expected [thus little
contention between threads], then why pool ?

Anyhow I'd need to synchronise over several calls within
MyCalendar to make sure the date is setup and retrieved
correctly:

synchronized public boolean isSpecialDay(Date date) {
setTime(date);
return isSpecialDay();
}

Presumably I should make all methods that set the date
synchronized also?

Offhand, I would say so, but I haven't looked deeply enough into this to say
for sure.

I know there is probably some bad stuff above, how
should I do this please?

Please view my comments as no more than idea contributions. You might want
to wait for more definitive responses !

Cheers,

Anthony Borla

 

[Chris Uppal]

At present there isn't a threading issue, just one thread. But I'd like
to make it thread safe, none the less. Also if there are multiple threads
eventually, I should convert my Singleton to an Object pool - right?

If there really is a significant execution overhead of creating these objects
then you could use thread-local storage instead.

-- chris

 

[P.Hill]

I have an application that deals with alot of dates, I have classes that
represent time & duration. I do not need to cart around the beast that is
GregorianCalendar.
However I do need to use it to convert data.

I think your concerns about object creation are over blown.

If you have an application object of some type that will need
a Calendar-like object, use late instaniation and then keep it
around for later.

If you do write an object that is not really a GregorianCalendar
you might consider at least imitating the method names of
the Calendar base class.
http://java.sun.com/j2se/1.4.2/docs/api/java/util/Calendar.html

Personally I would subclass GregorianCalendar, YMMV.

Also if there are multiple threads
eventually, I should convert my Singleton to an Object pool - right?

So whatever you do always get the object through a factory pattern
i.e. SomeObjectsWhichKnowsWhatACalendarIs.getMyCalendar(), so that if you
change form singleton to pool to whatever you can do it in one place.

Good luck,
-Paul