I don't think we necessarily need one for a project of this size. Take care, Sina -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of qubit Sent: Monday, November 15, 2010 4:27 PM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: BrailleBlaster Architecture Hi Sina -- as I slowly catch up on my email... Is there a design tool or methodology to use to specify brailleblaster at the design level? Brailleblaster is not such a large system that we couldn't start with some classes -- but I am not up to date on current practices for OO design. --le ----- Original Message ----- From: "Sina Bahram" <sbahram@xxxxxxxxx> To: <brailleblaster@xxxxxxxxxxxxx> Sent: Monday, November 15, 2010 12:17 PM Subject: [brailleblaster] Re: BrailleBlaster Architecture Agreed ... Something like this is not laid out in an email anyways. It grows organically underneath a particular design methodology. So, are we going to go agile/scrum or star/spiral topology model, etc, etc. MVC is rather simplistic, but might meet our needs perfectly. I think the discussion needs to occur at the design pattern and software lifecycle level, not at the class level. Classes are simply the latest infatuation of computer scientists to implement the instantiations of these conceptual techniques. Take care, Sina -----Original Message----- From: brailleblaster-bounce@xxxxxxxxxxxxx [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples Sent: Monday, November 15, 2010 12:58 PM To: brailleblaster@xxxxxxxxxxxxx Subject: [brailleblaster] Re: BrailleBlaster Architecture I think we still need to do work on naming of classes, I told you before some of this is meaningless in the name and won't help anyone find their way around. Main is a prime example of this, it represents main, can we have instances of main? To use the "we may as well call it" makes me think, well we may as well call it Bob or Henry. May be a few better names would be things like ApplicationInitialiser or Application controller, BrailleBlasterLauncher, etc. All the suggested names I have given would indicate to a new developer that the class will deal with starting BrailleBlaster. I would say that loading of settings should be dealt with in a separate class, eg. XMLSettings, which may be implements the Settings interface. This then means that in the future should we need to change the format of the settings file we know where to go or what to replace (eg. if we wanted to use ini files instead we could then create INISettings which also implements the Settings interface, and just drop that in place). I just use XML and ini files as examples there, we may use something totally different but you hopefully now get some of the power of object orientation and using interfaces. In my settings example I nearly went for having Loader as part of the class/interface names, but I decided not to go with that as it may be better to have it that Settings can reveal the settings as well as load them, as this then would mean other parts of the application can ask for the settings to be reloaded, or may be the settings object will automatically manage reloading settings as they change. Helpers is another example where I think further thought needs giving. It helps what? Is it helping with the actual window or handling the underlying document? Is the editor parts going to follow the MVC pattern? I could go on but I really don't feel like it. Michael Whapples On 15 Nov 2010, at 14:59, John J. Boyer wrote: > As I see it, the principal package in BrailleBlaster will be > org.brailleblaster.editor This will contain two large classes, > PrintWindow.java and BrailleWindow.java Code which these two classes > might have in common and which is identical for both of them should be > put in a third class called Helpers.java The editor package will > probably contain the entry point for BrailleBlaster. This class might > as well be called Main.java Besides containing the main method it will > do things like reading user preferences. > > There will probably be a number of small packages for bindings and so > on. > > John > > -- > John J. Boyer; President, Chief Software Developer Abilitiessoft, Inc. > http://www.abilitiessoft.com > Madison, Wisconsin USA > Developing software for people with disabilities > >