poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Javen O'Neal" <one...@apache.org>
Subject Re: Functionality injection technique for XWPF
Date Mon, 17 Oct 2016 05:17:59 GMT
I would recommend against reflection no matter what the code savings are.

On Oct 16, 2016 9:18 PM, "Mark Murphy" <jmarkmurphy@gmail.com> wrote:

> I found I should be able to do it using reflection to avoid long strings of
> instanceof conditions which is really the same as duplicating the code, but
> all inside one class. Any issue with using Reflection?
>
> On Sat, Oct 15, 2016 at 8:04 PM, Mark Murphy <jmarkmurphy@gmail.com>
> wrote:
>
> > In working through the XWPF API I see a lot of notation concerning
> > duplicated code. This is because there are a lot of places which need the
> > same functionality, but they are not related in a way that can easily be
> > sub-classed. For example a Document Body can contain Comments, Paragraphs
> > and Tables. So can Headers, Footers, Footnotes, and Table Cells. In
> > addition, Tables can contain Comments, but not Paragraphs or other
> Tables.
> > Same for Table Rows. The content functionality can be sub-classed by
> > itself, but  many of the objects that need to use that functionality
> > already have a place in the class structure, and cannot extend another
> > class. So I need another way to inject that functionality. I have an
> idea,
> > but would like some validation from others who are more versed in Java
> than
> > I, so here is the thought.
> >
> > I would create two base content classes: Markup which would contain the
> > implementation for comments, bookmarks, custom XML, and a few other
> things
> > which are used universally throughout the various content parts; and
> > Content which would extend Markup and add Paragraphs and Tables, and
> > anything else that is used exclusively where paragraphs and tables can be
> > added. Both of these would have associated interfaces which would be
> > implemented in the parts that need this functionality. The part I am not
> > totally certain about is injecting this functionality into XWPFDocument,
> > XWPFTable, XWPFTableCell, XWPFHeaderFooter, etc. My thought is to have
> each
> > of these objects implement one of the two base content interfaces, and
> > contain a reference to its associated implementation class. Then to
> > complete the implementation, it would forward requests associated with
> > these interfaces to the implementation class.
> >
> > So XWPFDocument would include something like this:
> >
> > XWPFDocument extends POIXMLDocument implements IContent
> >
> > ...
> > private Content _content;
> > ...
> >
> > public XWPFParagraph createParagraph() {
> >   return _content.createParagraph();
> > }
> > ...
> >
> > I know there are other things I would need to do because the XWPFDocument
> > class keeps a list of paragraphs and tables, and I would have to update
> > those lists, but this is the gist of how I would remove the duplication
> of
> > implementation details from all the places where it currently exists. A
> lot
> > of objects can create paragraphs and tables, and even more can create
> > comment and bookmark artifacts.
> >
> > What do you think? Workable? Any cons to this approach?
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message