Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
General <strong>Java</strong> Questions III<br />
http://www.patterndepot.com/put/8/<strong>Java</strong>Patterns.htm<br />
Q: I study patterns now and would be lost and forget everything very soon! Help!<br />
I am very new to design patterns and just bought the GoF book to learn about it.<br />
But as I complete the first couple of chapters right away, I see that they have 23<br />
different patterns and I would be lost and forget everything very soon if I sequentially<br />
(page by page) read the entire book!.<br />
Do any of you have recommendations on how to proceed with this book so that I 'll<br />
remember at least some of them by the time I am done with the book? I can see that<br />
many of the classes in java API use composition, facade etc...<br />
But other than that I don't think I 'll be able to gather anything unless I am able to<br />
remember where & when to use particular pattern A, B or C...<br />
Answer: Glad to hear you got the GoF book, it's a great reference manual for<br />
patterns. As you've found, however, it's a bit heavy to just "read." What I recommend<br />
to people is that they pick a few of the easier, more commonly used patterns:<br />
Singleton is a no-brainer that pops up a lot. Adapter tends to get used here and there<br />
and isn't that difficult to understand. If you're doing Swing, then definitely go learn the<br />
Observer pattern. It'll help to keep you from mixing data and interface code. Once<br />
you've learned three or four and have used them a few times, then as you start new<br />
projects, look back to the text to see if there are opportunities in your project where<br />
other patterns can be used.<br />
You'll find that over time you'll use more and more of the patterns (some a lot more<br />
than others, obviously). I've often found cases where I missed a pattern during<br />
design and had "the light go on" after I'd written a bunch of code and realized I was<br />
either using a known pattern by accident, or could have used a pattern to my<br />
advantage. When possible, I then go back and adjust the design/code to match the<br />
pattern.<br />
Keep in mind that the patterns generally don't appear as "absolute." It's expected<br />
that you may have variations to satisfy your application's needs.<br />
It's really helpful to others, however, if you make a quick note in your design<br />
doc/code about what pattern you were using (which helps them learn patterns too,<br />
and helps them understand what you were up to if they know the pattern already).<br />
--<br />
Rico Trooper<br />
Q: When I used java.util.Hashtable, I also used interface Enumeration. But I<br />
found that this interface contains defined methods.<br />
How can an interface contain defined methods? Isn't an interface supposed to hold<br />
abstract methods only?<br />
Answer:<br />
> How can an interface contain defined methods?<br />
No.<br />
> Isn't an interface supposed to hold abstract methods only?<br />
Yes. (and fields). I'm not sure why you think Enumeration contains defined methods,<br />
since it does not (I checked the source to be sure). Keep in mind that an<br />
implementing class is also of type Enumeration. So Hashtable's keys method which<br />
returns an Enumeration will actually be returning an inner class that implements<br />
Enumeration<br />
(and therefore defining hasMoreElements and nextElement in a manner that is<br />
file:///F|/350_t/350_tips/general_java-III.htm (7 of 9) [2002-02-27 21:18:30]
Change language