On 8/16/2012 7:33, Warp wrote:
> These have been cases where I have had an object which should act as a
> screen element (whatever the basic element may be called in a particular
> GUI library) and also as another class, neither of which could have been
> just an interface (because both base classes contained functionality of
> their own).

Yeah, OK, fair enough. I can see that. It's sort of what the MVC pattern is 
designed to get around, in a way.

Just as an amusement, I've found a very funky failure of inheritance at work.

We have a system that contains what we'll call documents. The business logic 
loads a bunch of documents, and then the UI has a bunch of subclasses of 
document that format the documents appropriately. (And the business document 
instantiates the appropriate subclass by looking at flags in the data and 
using factories and such.)  All well and good. You have documents, and you 
have SpreadhseetDocuments, PdfDocuments, VideoDocuments, TextDocuments, 
etc., all of which make calls to the superclass to get the parameters and 
then display the content appropriately.

Now we're doing a mechanism to let you edit documents, so we'll have 
DraftDocuments. But we want SpreadsheetDocuments, VideoDocuments, etc to use 
the data in the draft documents (which is stored in other tables, in funky 
formats appropriate for editing, etc) for previews. But I can't instantiate 
a VideoDocument with either a (final) Document or DraftDocument as the 
superclass as appropriate, because it's Java.  So I have to figure out a way 
around that somehow.

-- 
Darren New, San Diego CA, USA (PST)
   "Oh no! We're out of code juice!"
   "Don't panic. There's beans and filters
    in the cabinet."

Post a reply to this message