poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45919] [PATCH] Crucial classes made inheritable: HSSFWorkbook, HSSFSheet, HSSFRow and HSSFCell
Date Thu, 02 Oct 2008 05:26:28 GMT

Josh Micich <josh@gildedtree.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #6 from Josh Micich <josh@gildedtree.com>  2008-10-01 22:26:27 PST ---
>From a functionality perspective, you are probably tryng to do something very
sensible.  Can you please attach some sample code that shows your goal?

However, the technical change specified in these patches is contrary POI's
current direction.  POI avoids allowing API classes to be extended because of
the difficulties that this presents.  The trouble arises because inheritance is
such an intimate form of coupling.  

The most discernible difficulty relates to maintaining of backward
(source/binary) compatibility.  This link has some useful tables classifying
potential changes:

Much more subtle are the unexpected behaviour/logic consequences of
inheritance.  See this page for some well explained examples:

Most code using unwanted inheritance can be rewritten using delegation and/or
the 'strategy pattern'.

Don't get me wrong - inheritance isn't all bad.  POI uses *plenty* of
inheritance, just internally. My personal opinion is that "you should never
inherit from a class that you do not control the source code of".

Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

To unsubscribe, e-mail: dev-unsubscribe@poi.apache.org
For additional commands, e-mail: dev-help@poi.apache.org

View raw message