Re: Placement of Constants - again
On Thu, 27 May 2010, Rhino wrote:
"Tom Anderson" <twic@urchin.earth.li> wrote in message
news:alpine.DEB.1.10.1005271735220.16072@urchin.earth.li...
On Thu, 27 May 2010, Rhino wrote:
It's just one line of code:
ColorPalette colorPalette = ColorPalette.BLUES;
but I'm really struggling with where it needs to be.
Presumably, you have a Resume class (or even better, a
ResumePresentation). Who makes instances of that? Where does it get its
information from? Where, for instance, is your name stored?
The DATA on the resume is all stored in a ResourceBundle, including my name,
email address, job target, experience and all of that. The labels used to
present that information, like "Job Target", "Formal Education" etc. are
likewise stored in the same ResourceBundle.
I have a Resume class. It's job is to find the obtain the information from
the ResourceBundle. It is basically a bunch of small getters, like
getJobTargetText() which returns the label "Job Target" (it would return the
French translation of Job Target if I create a French-language resume) and
getJobTargetData() which returns the jobs that I am targeting with this
resume.
Okay, then make the palette a property of the Resume class. Other code
which is interested in the palette says:
Resume r;
ColorPalette = r.getPalette();
You then just have to decide how to implement that getter. I'd start with
the simple way:
public ColorPalette getPalette() {
return ColorPalette.BLUES
}
If you later decide you want data-driven palettes, you could load the
choice from your resource file, or from some other configuration file.
The important point is that everyone who needs to know a palette can just
ask the Resume for it.
I don't have a ResumePresentation class at all. Is a "Presentation"
class part of one of the design patterns?
No, sorry, i was thinking out loud and hoping that the name would make my
meaning clear, which of course it doesn't even come close to doing.
My thinking was that there's a difference between a resume (information
about who you are and what you've done) and the way a resume is presented
(layout, fonts, colours, etc). My suggestion above of putting the palette
on the Resume object conflates these two ideas. Now, conflation isn't
acutely poisonous, but it's a chronic toxin that should be avoided. In
this case, i was thinking of factoring out a ResumePresentation class that
held presentation-specific information. The palette would then be a
property of that. You could have the ResumePresentation class refer to the
Resume it presents (but not vice versa - a resume should not know or care
about its presentation), or you could make ResumePresentation
Resume-agnostic, and only have them interact when the time came to do some
presentation.
All of the classes in the project share a common set of
ResourceBundles. (I want to keep open the possibility of generating
resumes in foreign languages since I have a working knowledge of two
other languages and could picture working in countries where those
languages are spoken. I haven't actually translated phrases like "Job
Target" or "Format Education" to the other languages but I _could_ and
might do that.) The base name of the ResourceBundles is used in both
ResumeFileGenerator and ResumeApplet. Where should I put its
definition so that both classes use the exact same name?
Same problem as above. This belongs to whoever is in charge of making
Resume objects. If there are several places where Resume objects are made,
then refactor until there is only one, and put it there.
Hmm. I'm not sure I'm understanding you correctly. Based on my
description so far (in the original post and this followup) would you
agree that ResumeFileGenerator is the place where the Resume objects are
made? Or are you talking about the specific classes that generate each
Resume, like ResumeFileWriterAscii, ResumeFileWriterHtml,
ResumeFileWriterPdf and so forth? And what about my standalone
ResumeApplet? The resume in that is NOT created by ResumeFileGenerator.
In which case the second sentence in the paragraph applies. Factor out a
factory for Resumes (which could be as simple as a static factory method
on Resume), and share it between the ResumeFileGenerator and the
ResumeApplet.
tom
--
Also, thinking about that Velociraptor thing, I think -- what with having
trained on turkeys, guineafowl, geese, large chickens, swans and peacocks
as a child -- that I could take a Velociraptor. I'd need a large hessian
sack, some baler twine, and a hook to hang it from. And gloves. Not to
forget the gloves. -- cleanskies