> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]]
>
> Berin Loritsch wrote:
> >
> > Keep in mind what the purpose of services and information are. A
> > service acts on information, provides information, or changes
> > information.
> >
> > In both FOP and POI, you have a complex document format, and
> > relatively few services. That is fine. Let your services focus on
> > *doing*, and your document format focus on representing the
> document.
>
> Yes, but object shave methods, not only data...
However what do those methods do? Do they add a new document portion,
remove it, or something more complex?
If it is a service, it probably needs to be factored out.
<snip/>
> Ah, ok.
> The fact is that The OM is basically reactive, in a sense
> that the data
> structure is able to reply to methods, which are used by the
> builder via
> a common interface for all objects.
Pretty much.
> How do these methods get hold of common library services?
They don't. The services are performed on behalf of the object
model by the parent service. When the document fragment is
built, it is attached. That means for some types of fragments
like images, you have to have an image descriptor so that the
Adaptor service at the end so that the adaptor knows how to
retrieve the real resource.
> The common solution is use of static stuff, like in log4j,
> where to log
> inside these data structures I get a logger via the static method.
>
> It's a cross-cutting concern, so I cross-cut the hierarchy via static
> methods.
It's a common thing to do, however you do need to be careful with
statics. Statics are the antonym of components. Components protect
against refactoring because you work with known interfaces, and
encapsulate logic neatly. Statics hinder refactoring because there
are always undocumented dependencies on the static. Once you
change a static to non-static you will find that no matter how
religious you were about documenting the dependencies, you will
find that the changes are more far-reaching than you expect.
So what to do?
Use "descriptors" or enable fragmenting the document so that you can
build the parts in pieces and reassemble them later when necessary.
The output adaptor is reactive in that it responds to the document
model, and converts it to a stream. If you use "descriptor" objects,
you can delay things like grabbing an image until you need to serialize
it. You can also deploy a document "validator" service to ensure
everything needed for the document is there.
> > Like I said above, adopt a proper design pattern like the "builder"
> > pattern, and when the time comes for the ImageFactoryService to be
> > used, the builder accesses it.
>
> Ahhh...
>
> > Or perhaps it is not the builder
> > that uses it, but the adaptor that serializes the information to a
> > stream. Either way, it is used by the proper service.
>
> Now I get your idea better...
> Instead of
>
> method(unresolvedparam){
> resolved = getService().resolve(unresolvedparam)
> use(resolved);
> }
>
> I should do
>
> method(resolved ){
> use(resolved);
> }
>
> :-D
Yep. Or even better, your service acts on the document model,
and the document model only holds information!
> >>How can I make these components serviceable?
> >
> > Do not make services out of objects.
>
> IE, objects shouldn't use services at all.
Pretty much.
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
