[brailleblaster] Re: Writing extensible Java code
- From: "qubit" <lauraeaves@xxxxxxxxx>
- To: <brailleblaster@xxxxxxxxxxxxx>
- Date: Sat, 6 Nov 2010 15:09:38 -0500
LOL about Jimmy Hendricks.
But I don't quite see your point in the first paragraph of your mail. It
seems the orchestra example is just the same as the band example (although I
omitted the code to allocate the array). Of course I mention abstraction
and specific implementation in defining virtual methods, but this is what
java uses to provide polymorphism. I haven't cracked a theory book in a few
too many years so perhaps you are splitting hairs on the definition of
polymorphism.
--le
----- Original Message -----
From: "Michael Whapples" <mwhapples@xxxxxxx>
To: <brailleblaster@xxxxxxxxxxxxx>
Sent: Saturday, November 06, 2010 1:48 PM
Subject: [brailleblaster] Re: Writing extensible Java code
I think your example probably caught more than just polymorphism. You
mentioned the idea of abstraction and specific implementation (ideas used in
designing the objects) where as polymorphism I think relates more to when
using it you only need to know the specific item is a type of the more
general one, rather than knowing what the specific type is. As an example,
you may represent a band as a collection of instruments in java (eg.
List<Instrument> band = new ArrayList<Instrument>(); ), then we could add
any type of instrument to that and other code need not worry about what
specific type it has, they can all play music as they are instruments.
Also remember you can have many layers of subclassing, with each layer
representing a different level of generalisation. Using the instrument
examples we can separate them into types of instrument before naming the
individual instruments, wind, brass, string, etc, all with things specific
to the group, eg. you can blow a wind instrument but might have trouble
doing that to a string instrument (unless we're planning on following Jimmy
Hendricks in experimenting with new ways to play a guitar).
Michael Whapples
On 5 Nov 2010, at 22:45, qubit wrote:
> 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:
