|Java Programming Exercise|
Review: Here is a Java Programming Exercises
Just as Physics is looking for its Grand Unified Theory that will bring the gravitational, electro-magnetic, weak nuclear, and strong nuclear forces into a single complete model, IT is looking to bring its four major development paradigms - 1)user interfaces and interactions, 2)data persistence and integrity, 3)resource mapping and monitoring plus 4)process scheduling, sharing and workflow control into a unified development approach. That approach is intended to finally deliver systems that are not only functional but also flexible and adaptable to constantly changing needs and requirements. The intent is not only to be able to deliver working systems with a high success rate but to be able to maintain, adapt and even re-use large portions of those systems in new and evolving contexts. Finally such an approach will be judged not only by its success rate but also by its ability to minimize wasteful overlap, avoid fragility to attack, and yet still be agile in modification and maintenance.
Currently SOA is being offered as the IT framework that will deliver this unified development approach. And it certainly does a good job on aspects of the problem - particularly resource mapping plus process scheduling, sharing and workflow in a more unified fashion. But SOA stands almost silent about the user interface and interactions, always subsumes everything into its XML framework without utilizing alternative methodologies and has a mixed record on specifying and supporting the metadata necessary to supply a robust control and reuse infrastructure. So if you think SOA governance is tough to do - what happens when SOA Provision does not have the scope to carry the load.
So these exercises, while touching on very specific Java problems , will also be attempting to relate the issues encountered to this broader, grand unified theory of development. But also I will attempt to point to books, articles and tools that attempt to address these issues. And then, more than occasionally, I shall attack a problem for the sheer interest of it and/or my need to know how exactly this is done within Java.
To avoid this wastage of memory use Java's StringBuffer or StringBuilder classes. The two classes are nearly identically the same in methods supported with the notable difference that StringBuffers are thread-safe and StringBuilders are faster. I chose to stay thread-safe in this example and used the StringBuffer class. For more details see Sierra and Bates page 669.
Now the second problem involves passing parameters into parseFloat(). I want it to return three values - 1)the value of the numeric field, if any, as a floating point number, 2)the number of characters left to parse in the StringBuffer strinb parameter, and 3)strinb also passed back and truncated of the numeric field so that I can parse the remainder straightforwardly elsewhere.
This requires a quick review of parameter passing in Java. All the primitive data types like boolean, int, float, etc are pass by value. This means that substitute values are placed into the parameters before calling the method which prevents any changes to primitive datatype parameters like int and double inside the called method. But this is opposite of what I want. For example I want the parameter leftover to tell me how many characters are left over in the string after parsing. However, to the rescue is the fact that objects are passed by reference, so any changes made to them in the called method are also "returned" to the calling method(in point of fact the same memory is referenced in both methods - so the object if changed will be passed back - so just make leftover an Integer object.
Now there is a problem with this routine. The wrapper variable, Integer left, despite being an object, also like Strings turns out to be immutable. It can't be changed once assigned to. So there is no convenient way to pass back changed primitive parameters like int, Integer, float, Float, etc in a Java method. Now why Java designers chose these design characteristics is a mystery to this party (I have done the appropriate Google search for why - no luck so far). As Jacquie Barker points out in her excellent book on Java Objects(page 352-3), wrapper classes like Integer and Float are vital to Java containers class usage. So this is sort of a Java conundrum like why Java class and package identifiers are tightly coupled to file and directory names respectively - another piece of "why-for-art-thou" that diminishes Java's usability.
Finally let us consider the use of the two static methods, isnum() and parsedFloat(). There is a disadvantage to static methods, you cannot use either instance variables or methods from which the class static methods are contained in (class floats in our example). But that turns out to be no real burning restriction. Since class floats does not have any non-static methods or refernces to class variables except as passed legitimately as parameters. The personal advantage to me is that I have a big myutils.jar file filled with my frequently used static methods similar to Java's own Math class. These are routines that are cross class in nature - a shortcut to full blown AspectJ-type programming.
Meanwhile anybody who can do the following:
So what have we learned ? Last first, it is fairly simple to create a parsedFloat() counterpart to parseInt(). Second, static methods have there place in Java usage. Third, a little bit about StringBuffer/StringBuilder usage as substitute for Strings. And last but not least, passing parameters in Java are simple, maybe too simple.