--- Jeremias Maerki <[EMAIL PROTECTED]> wrote: > > > > Personally, I would rather we get rid of > > RendererFactory and put the logic back where it > > was--in FOTreeBuilder and RenderPagesModel. This > > functionality is just too specific to be reused > > elsewhere in FOP. > > I don't see your point and you were the only one who > complained about > the RendererFactory. I still think the > RendererFactory is A Good Thing > (tm). It reduces imports, dependencies and number of > lines in > FOTreeBuilder and RenderPagesModel....
I don't see how adding a class in the renderer package, which fo.FOTreeBuilder and area.RenderPagesModel now must access in order to do their work, reduces the number of dependencies and imports. (Indeed, we now have a new dependency: RendererFactory.) Also, the fact that the new solution has more classes and more overall LOC would appear to invalidate the benefit of there being fewer LOC in FOTB and RPM as a result. Usually for a factory pattern, its biggest selling point is in reuse--i.e., centralizing certain logic so it doesn't have to be duplicated in multiple places. But there is no reuse being realized here. (Perhaps you see some in the future however.) > and centralizes > instantiation of the > Renderers and FOEventHandler in one place where they > are easier to find > for those unfamiliar with FOP sources. > True--but is that an acceptable OO design? Can we indeed just rip out disparate business logic from various classes and place them into one class for convenience? Is there really an object that would know which FOEventHandler an FOTreeBuilder requires *and* which Renderer the RenderPagesModel needs? (They are different issues, after all.) RendererFactory seems to be a C-language-like non-OO collection of business logic, an artificial object, and the fact that it has no class or instance variables would appear to add to that argument. Still, this is just one additional class so hardly an architecture-breaker. (And I can see the convenience regardless of having them together in one place.) So just take this posting as a desire on my part to further clarify my concerns about this class. Thanks, Glen
