poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominik Stadler <dominik.stad...@gmx.at>
Subject Re: Abstract classes vs Util classes
Date Tue, 19 Jan 2016 09:10:14 GMT
Hi,

I'm also in favour of keeping the interfaces, for me it provides a very
concise and clear API for users, we should not clutter this with
implementation details.

One other possibility would be an intermediate abstract class which
collects these "common" code, i.e. AbstractWorkbook, AbstractSheet, ...
This should also be mostly backwards compatible.

Dominik.


On Tue, Jan 19, 2016 at 8:34 AM, Javen O'Neal <javenoneal@gmail.com> wrote:

> > Also, is there that much that's common for (eg) HSSFCell & XSSFCell &
> SXSSFCell & that proposed hybrid sax reading thingy?
> How about [1] XSSFSheet.copyCellFrom(Cell, CellCopyPolicy), which I
> haven't added to HSSFCell and the Cell interface yet partially because
> I didn't want to duplicate the code.
>
> Skimming through XSSFSheet and XSSFCell, I didn't see as much
> code as my memory had though that looked generic enough that it
> could be written once withoutvreferring to implementation classes.
> The methods that could benefit are mostly higher-level concepts
> like shiftRows and copyRows, though we might not be able to move
> these up if they rely on class-private data structures.
>
> For now it sounds like we're best off to leave the class hierarchy as
> is. When adding new code that is identical for HSSF and XSSF, say for
> example validateMergedRegions for bug 58885, should I move the
> would-be-duplicated code out to a *Helper (or *Util if helpful for
> external usage), or duplicate the code?
>
> Thanks for the discussion, folks!
>
> [1]
> http://svn.apache.org/viewvc/poi/trunk/src/ooxml/java/org/apache/poi/xssf/usermodel/XSSFCell.java
>
> On Mon, Jan 18, 2016 at 9:29 PM, Nick Burch <apache@gagravarr.org> wrote:
> > On Mon, 18 Jan 2016, Javen O'Neal wrote:
> >>
> >> There are certainly some good cases for having Util classes, but
> sometimes
> >> the best thing is to have the functionality right in the class. The
> problem
> >> is there is no place to put code that would be used by all implementing
> >> classes besides a utility.
> >
> >
> > Minor naming thing - on the whole, we use *Util classes for things that
> end
> > users will call, and *Helper for things that POI will internally call.
> Isn't
> > always consistent, but that's generally the plan!
> >
> >> Perhaps we should convert Workbook, Sheet, Row, and Cell (and really
> >> everything) to abstract classes so that generic code can be written in
> one
> >> place rather than duplicated across implementing classes.
> >
> >
> > That'd sadly break backwards compatibility for almost all of our users,
> even
> > if only at the binary level.
> >
> > In the past, there has been talk of other formats (eg ODF) implementing
> our
> > interfaces to get consistent handling for their spreadsheets too. I
> haven't
> > heard of any public implementations of that, but there may be private
> ones
> > that we'd risk breaking
> >
> > Also, is there that much that's common for (eg) HSSFCell & XSSFCell &
> > SXSSFCell & that proposed hybrid sax reading thingy? (Genuine question!)
> >
> > Nick
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> > For additional commands, e-mail: dev-help@poi.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
> For additional commands, e-mail: dev-help@poi.apache.org
>
>

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