I also am not fully convinced. As mentioned before may be some higher
level design needs to be thought through before trying to implement it
in a specific programming language. Again still some of the names aren't
really clear, commons, common for what? Common stuff for document views,
etc.
Here is my thoughts:
There is a TranslatedDocumentView and a DaisyDocumentView. Both of these
are DocumentViews. Now I don't know whether there is enough in common
between the two types of DocumentView for the two to inherit code from a
common document view, but both probably will have the same operations
(eg. moveCaret, insertHeadingAt, etc), so should implement an interface.
There is a good reason for this, see lower down.
Something is going to have to handle/manage the document, liblouisutdml
may do much of this but we probably will want something more suited for
document manipulation (eg. providing facilities like insertHeading,
insertParagraph, insertText, deleteHeading, etc) for use in this part,
so there probably is a DocumentManager which will use liblouisutdml. The
DocumentManager will need access to the DocumentViews to let them know
about updates to the document as it is edited.
Now this is where I feel all this thinking of classes only has obscured
the actual design. We have stated multiple views of the document
will/can be shown at one time and changes in one document view will
alter the other. Reading some of the stuff about the MVC pattern, may be
combined with the observer pattern, this could be done using those
patterns. That is why it would be important for there to be a
DocumentView interface even if there was no abstract class for the
TranslateddDocumentView and DaisyDocumentView to inherit from.
John, you talk of making a basic editor initially, is this another
DocumentView? If it were then it means that after that its only a matter
of creating the more advanced views and may be developing the
DocumentManager further should it need extra abilities.
Michael Whapples
On 30/11/10 15:11, qubit wrote:
Hi John --
I still am not satisfied that that is the best breakdown, but will look
again and think about it a bit. I don't know what you have in mind; iI
only
comment that if it were me choosing division of labor between the classes,
I
wouldn't make the wpmanager a subclass of common, like the braille and text
windows, as their purpose is a little different.
If this were C++ and if you had methods that need to be members of several
varying classes, you might consider using multiple inheritance. But even
that would be questionable in my view.
Just elaborate on what exactly the wpmanager should be responsible for, and
what the text and braille panes are responsible for. The common class is
just a superpane that gathers all the common activities of the text and
braille panes. The wpmanager is responsibility for word processing rather
than display attributes.
At least that's how I'm making sense of it. Not that that is the only way
to
do it -- so I'll be interested in your elaboration.
Hey, Yuemei, this is your section of code -- what do you think belongs
there?
Just musing to help the process along.
--le
--le
I am thinking that separation of various types of operations is in order.
----- Original Message -----
From: "John J. Boyer"<john.boyer@xxxxxxxxxxxxxxxxx>
To:<brailleblaster@xxxxxxxxxxxxx>
Sent: Tuesday, November 30, 2010 1:18 AM
Subject: [brailleblaster] Some Design Considerations
Laur's idea of using subclassing in the word processor looks like a good
design approach. As I see it, the Commons class would be renamed
WordProc and it would be the base clas for all other classes in the
wordprocessor package, WPManager, BrailleWindow, DaisyWindow
StartupScreen and TextEditor. It will have a static initializer that
establishes the interface with SWT and it will contain methods for
performing common tasks.
I am thinking of concentrating my efforts, for the time being, on some
of the subcommands, setting up the framework for the wordprocessor and
coding the TextEditor class. If we implement Alex's idea as I described
earlier we will then have a first cut for BrailleBlaster. The
wordprocessor package can then be fleshed out, adding features
incrementally. Thus we will have a more and more capable application.
John
