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 <jmarkmur...@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?

Reply via email to