One thing I would say, don't use static for member variables unless there is a really good reason. You would be limiting yourself to only one Braille window and one daisy window, even if you have multiple WPManagers.
There is an undefined part of the design, should it be possible for BrailleBlaster to allow multiple documents to be open at a time like you can in word?
Michael Whapples On 01/12/10 00:49, qubit wrote:
John, I agree that we are thinking in java here (like the book title says) and so abstractive to be language independent serves little purpose. However, I still question making the wpmanager a subclass of the common window (for lack of a better term). Essentially, you inherit from a common class when you want the subclasses to be specialized instances of the parent or superclass. The WPManager, as far as I can tell, is not a window that can be dragged around or resized like the daisy and braille windows. It is simply a behind-the-scenes entity that controls what to do with the display windows. From its choice of name, I also gather that WPManager will be munging with the jdom objects. This has nothing at all to do with common window control, except that it may invoke methods in the daisy and braille window objects. This does not imply that WPManager needs to inherit from the common class. Now I would treat the class hierarchy as follows: class CommonWindow /*..possibly extending some class ...*/ {} class DaisyWindow extends commonwindow class BrailleWindow extends commonwindow class WPManager { public static DaisyWindow DW; public static BrailleWindow BW; /* ... lots of stuff ...*/ } Does this misrepresent the problem? --le ----- Original Message ----- From: "John J. Boyer"<john.boyer@xxxxxxxxxxxxxxxxx> To:<brailleblaster@xxxxxxxxxxxxx> Sent: Tuesday, November 30, 2010 4:33 PM Subject: [brailleblaster] Re: Some Design Considerations Here are some more thoughts on design. There will actually be two sets of common operations, one for the various windows and one for creating and manipulating JDOM trees. They should be in separate classes, perhaps called WindowCommons and JdomCommons. The WindowsCommons class would set up SWT in a static initializer and provide methods that any window could call. I'm quite sure there will be a considerablenumber, based on past experience. The various window classes would be subclasses of WindowCommons, since they must all share the same SWT Display instantiation, etc. I don't see the advantage of an interface over subclassing. JdomCommons would have to be imported into the various classes.itwill simply encapsulate JDOM operations into convenient methods. Some of them could be quite complicated. The bare-bones text editor would be a third window or view. It would work only on text files and would be used by advanced users who wish to create or edit translation tables and templates. It would be a subclass of WindowCommons. It would not import JdomCommonns. I think WPManager will have to be a subclass of WindowCommons, since it will have to co-ordinate the Daisy and BrailleWindow views. It is actually mostly a windows manager, but it is the entry point to the word processor. It will also call the TextEditor if requested by a cubcommand. The TextEditor will work alone and will not share space with either of the other windows. Developing it first is a development strategy to get a feel for SWT and see what should be in WindowCommons. I don't see what we would gain by trying to think of the design in a language-independent way at this point. After all, if we are writing in Java, why shouldn't we think in Java? John On Tue, Nov 30, 2010 at 03:49:36PM +0000, Michael Whapples wrote: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
