A design tool, I am not sure how necessary but I would say we should certainly have a design.
What I mean by this is, you say break things down into modules, fine, but objects/classes aren't quite that, they are just a technique in use in some programming languages. The questions are, how do the modules fit together, what are the precise responsibilities of each module, how do the modules pass information around, etc?
May be an example of how a class isn't a module, you probably would not have a date module, however it can be very useful to have a date class. The reason one would use a class for date would be that the actual way the date is stored need not be known by the rest of the application, it just needs to know how to operate the date class (eg. getMonth, getDay, getDayOfWeek, getLocalTime, getLocaleDisplayDate, etc). This means that should another way of storing the date data be needed you only need modify the date class (eg. You may have started by saving the date in a long, but then you may wish to store day in a short, month in another short and year in an integer, imagine the difficulties you would have if any part of the application could directly access the original long storing the date).
Michael Whapples On 16/11/10 09:35, John J. Boyer wrote:
I am frankly skeptical about using a design tool. It might just distract us and waste time. My approach to programming projects has always been to divide the project into pieces and assign each of these pieces to a module. That worked well for liblouis and liblouisutdml. Of course modules were added, merged and dropped during the development process. I am just applying the same method to BrailleBlaster. The classes I have proposed, already with some modifications, correspond to the main functionality of BrailleBlaster. Do we really need a more "sophisticated" approach. What would it get uls that we don't have already? John On Mon, Nov 15, 2010 at 03:27:13PM -0600, qubit wrote: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
