[brailleblaster] Re: BrailleBlaster Architecture
- From: "Sina Bahram" <sbahram@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Tue, 16 Nov 2010 07:52:54 -0500
I can't agree more. Sorry, I'm not going to participate in class level
discussions right now.
We need a functional spec.
Take care,
Sina
-----Original Message-----
From: brailleblaster-bounce@xxxxxxxxxxxxx
[mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of Michael Whapples
Sent: Tuesday, November 16, 2010 6:04 AM
To: brailleblaster@xxxxxxxxxxxxx
Subject: [brailleblaster] Re: BrailleBlaster Architecture
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
>>>
>>>
>>
>>
>>
Other related posts:
