• 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

Class Structure in GWT Exmaple

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
So I was digging through the code examples for Google Web Toolkit and I came across this example code for the KitchenSink Project. I was looking at the Sink Class and how its structured and initialized and I couldnt help but wonder why they did it the way they did.

Sink Class
1. Abstract... so its meant to be derived from.. fine
2. Derived from another class Composite...fine
3. Now instead of storing 2 fields for name and description for the sink name and description. It has another abstract static class inside it. The abstract static class also contains an instance of the Sink class and is used to return an instance of the Sink object itself.

So Why did they do it this way (example A) and not simpler (example B)
What was the advantage of using an abstract static class inside ?

Example A



Example B.
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Looks like "lazy instantiation" is the key. Just guessing - Composite must be a relatively expensive class to instantiate so they don't create it until they need it. You could create a bunch of SinkInfo objects at relatively low time and memory costs. Then when you really need a Sink you can ask a SinkInfo for an instance. Only then does the SinkInfo make a Sink instance. Does that fit with the rest of what you know about GWT?
 
Udit Manektala
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
aha!!
Here's a code comment
/**
* A 'sink' is a single panel of the kitchen sink. They are meant to be lazily
* instantiated so that the application doesn't pay for all of them on startup.
*/
 
Ranch Hand
Posts: 1296
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thats kinda cool. Don't know where I'll ever need that, but I'll keep it in the back of my mind regardless.
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
It's also a separation of business stuff, like the name and description, from the GUI stuff like hide and show. Oddly, the dependency runs the "wrong" way ... the Info knows about the GUI Sink.
 
Bartender
Posts: 2968
6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, I think another significant motivator can be found in here:



The SinkInfo class also serves as the creational interface for the Sink class. Typically interfaces cannot define, constrain or guarantee the presence of certain class constructors in their direct implementations. However this interface guarantees that you can create the correct Sink implementation if you got a hold of one of its SinkInfo instances - meanwhile the class client remains totally oblivious to which SinkInfo AND Sink class it is dealing with (while knowing that any Sink created does belong to the SinkInfo class that is was handed). Furthermore it defers the decision of how the Sink Implementations are actually created - they could be lazily instantiated but they could also be sitting ready to go in a repository waiting to be looked up.

Add a competently implemented equals and hashcode method to the SinkInfo class then you could also have a business key class that could be used in maps to organize all the Sink implementations and instances...
[ March 26, 2007: Message edited by: Peer Reynders ]
 
reply
    Bookmark Topic Watch Topic
  • New Topic