• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Instantiation of abstract i18n classes using static factory methods

 
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello everybody,

I am reading Sierra/Bates chapter 6 on i18n, where 'tis explained that the instantiation of the 3 abstract classes util.Calendar, text.DateFormat and text.NumberFormat can only be done through static factory methods (get<Xxx>Instance()). The book does not elaborate further, and I don't blame them, still I'm curious...

What I am wondering about is why it is so. Does anybody know or can speculate why the abstract factory method pattern was chosen by the mythical Java API designers? Why should this design approach be deemed more suitable (I assume that it is?) than the good olde overloaded constructor approach, as with the old util.Date class?

BTW, I did google around on this subject, but online articles on this subject are rather dense, cryptic and too generalized; and I'm specifically curious about these 3 classes Calendar, DateFormat, NumberFormat. Perhaps some ranchers here can offer a brief explanation?
 
Greenhorn
Posts: 5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,
May be you have missed right keywords in Google to find the correct results for your question.

There are more benefits when you use static factory methods instead of a constructor.

Look at this blog for more

Java Tip

It may be helpful
 
Ranch Hand
Posts: 513
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
The abstract factory pattern is used for a lot of things, but its most important characteristic is that it hides the actual concrete implementation class from the client code. In other words, Calendar.getInstance() might actually give you an GregorianCalendar or AlGoreDoomsdayCalendar, but all you know is that you're getting some kind of Calendar. This pattern is very useful for promoting loose coupling, and it's used extensively in OO design.

Contrast this with direct instantiation, where the client code must know the exact concrete class.
 
Marcus Jastrebowski
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thanks Kelvin, that's a very nice explanation, and I am beginning to see the light.

Still I have some doubts... Loose coupling is paramount in OO, sure. But don't clients need to know exactly what type of Calendar instance they get and demand that they get it? In other words, what if I specifically must get the AlGoreDoomsdayCalendar -- but the Calendar.getInstance() method will not offer or guarantee it to me? How do I go about it then?

Marcus.
 
Ranch Hand
Posts: 1274
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy!

The factory pattern is used when the calling class does not know or does not need to know what concrete class will be instantiated or when the calling class does not know how to instantiate the concrete class.
The Calendar API just tells you about the method getInstance:
Returns:
a Calendar.



If you know you need the special Al Gore doomsday calendar, you simply cannot use the getInstance method of class Calendar.
You would have to instanciate the doomsday calendar on your own or - if the AlGore class is a factory as well - use their getInstance method.


To Silicon Oyster:
Nice link.
Please have a look into your private messages by clicking the "My Private Messages" link near the top of this page.


Yours,
Bu.
 
Marcus Jastrebowski
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you gentlemen! Your answers have cleared it up a lot. I get the picture now.

Marcus
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic