[brailleblaster] Re: BrailleBlaster Architecture
- From: "Sina Bahram" <sbahram@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Mon, 15 Nov 2010 13:17:52 -0500
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:
