[brailleblaster] Re: Writing extensible Java code
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Fri, 5 Nov 2010 17:45:17 -0500
Hi John -- Hmm -- I thought the example with the instruments was a type of
polymorphism. But maybe I'm mistaken.
As for the embosser files and drivers, that appears to be accessed through
the java bindings to your C libraries -- do you think it should be broken up
further?
--le
----- Original Message -----
From: "John J. Boyer" <john.boyer@xxxxxxxxxxxxxxxxx>
To: <brailleblaster@xxxxxxxxxxxxx>
Sent: Friday, November 05, 2010 1:19 PM
Subject: [brailleblaster] Re: Writing extensible Java code
Laura,
Thanks for the clarification of abstracting things in Java. I think
another way of making Java code extensible is through polymorphism. As
Sina says, extensibility is a big subject. One place where we could use
the king of abstraction you describe is for embosser drivers. We will
also want to produce various types of output files, such as PEF and brf
files that can be loaded onto a notetaker and read with a braille
display.
John
On Fri, Nov 05, 2010 at 12:32:40PM -0500, qubit wrote:
> John, I think that you can take your example of using named constants in C
> and note that not only can you abstract constant data names in java, but
> also types and methods.
> So if you have a musical instrument class with methods play() and data for
> pitch range and key, you can define subclasses for class flute, class
> oboh,
> class cello, etc. All of these will define method play(). But you don't
> need to know the type of an instrument at compile time -- just build an
> orchestra as a list of instruments, and then for all the collection you
> play
> whatever musical parts are required for that instrument.
>
> Hope this clarifies -- this makes it possible to define libraries that can
> be linked to the application and run without requiring much information
> about the internals of the library.
>
> This type of thing harks back to my C++ days. I think Java is not C on
> steroids, but is better described as a subset of C++ on steroids. But
> that's not altogether true also as the semantic and scope rules are
> slightly
> different.
> Java is its own language. I'm liking it more every day.
> Now if I can get eclipse to work...
> --le
>
>
>
> ----- Original Message -----
> From: "Sina Bahram" <sbahram@xxxxxxxxx>
> To: <brailleblaster@xxxxxxxxxxxxx>
> Sent: Friday, November 05, 2010 10:04 AM
> Subject: [brailleblaster] Re: Writing extensible Java code
>
>
> There are many discussions of this issue, and in fact entire books have
> been
> published on the subject.
>
> What exactly are you looking for? Design patterns, coding practices,
> continuous integration methodologies, software engineering
> paradigms?
>
> Take care,
> Sina
>
> -----Original Message-----
> From: brailleblaster-bounce@xxxxxxxxxxxxx
> [mailto:brailleblaster-bounce@xxxxxxxxxxxxx] On Behalf Of John J. Boyer
> Sent: Friday, November 05, 2010 2:50 AM
> To: brailleblaster@xxxxxxxxxxxxx
> Subject: [brailleblaster] Writing extensible Java code
>
> The discussion of using BrailleBlaster on various device has set me
> wondering which Java coding practices lead to extensibiloity. In
> C, one of them is to avoid hard-coding connstants into executable
> statements.
>
> I like to think of Java as C on steroids.
>
> 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:
