I think what I really was trying to get at in the first paragraph was abstraction/reuse was also covered by your example and abstraction is more related to the design time (identifying what is common to which items and which things do them in the same way). To give an example we may have two Braille translator's which use different algorithms but they both can write the result to disk. Here both are Braille translators, both able to translate and write to disk, so it seems simple to say these could be in a super class. Now I did define them as using different algorithms so the implementation of translation should be further down in the specific classes, but write to disk, that seems to be common to both and I don't see any reason why it would need to differ for the two specific types. This means write to disk could be implemented at the generalised Braille translator super class level (in java this would need an abstract class instead of an interface, although it still would be good to have the interface above this abstract class).
Now back to polymorphism, its meaning could be put as "can take many forms". Now this has actually slightly stumped me, polymorphism in object orientated languages actually mean the general type can take many forms or does it mean an initialised object can be changed to another form. I think its closer to the first from a quick look on the internet, its to do with using different types in the same way. Interestingly I did see a suggestion that polymorphism does not rely on classes deriving from the same super class, may be hard in Java (if you count interfaces as part of the inheritance tree, not so hard if you go with classes don't inherit from interfaces they only implement an interface) but dynamic languages like python that is perfectly possible. Anyway the point really being here we are dealing with how one uses classes and objects elsewhere in the programme.
While may be interesting, it may be a little bit splitting hairs as far as practical use goes, you had given a fairly good summary of object orientated ideas, may be I am just trying to pick out subtleties which might get missed.
Michael Whapples On 06/11/10 20:09, qubit wrote:
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
