[brailleblaster] Re: BrailleBlaster Architecture
- From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
- To: brailleblaster@xxxxxxxxxxxxx
- Date: Tue, 16 Nov 2010 05:47:33 -0600
Thanks for the clarification of modules and classes. I'm learning a lot.
John
On Tue, Nov 16, 2010 at 11:03:36AM +0000, Michael Whapples wrote:> 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
> >>>
> >>>
> >>
> >>
> >>
>
--
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:
