Singleton with lazy initialization implementation:
final class Singleton {
private static Singleton s;
private static int i;
private Singleton(int x) { i = x; }
public static Singleton getReference() {
s = new Singleton(47);
return s;
}
public int getValue() { return i; }
public void setValue(int x) { i = x; }
}
without lazy initialization:
final class Singleton {
private static Singleton s = new Singleton(47);
private int i;
private Singleton(int x) { i = x; }
public static Singleton getReference() {
return s;
}
public int getValue() { return i; }
public void setValue(int x) { i = x; }
}
So points to note about the singleton pattern:
1) we have to create our own private version of the constructor in order to suppress the default constructor which will be spawn by the compiler.
2) we will create a public getReference() or getInstance() method for client to access the class.
3) we will take extra caution about ensuring class members are static if we wish to implement lazy initialization.
4) we will make the class final in order to prevent client to extend this class and make it clone able accidentally.
Showing posts with label I create. Show all posts
Showing posts with label I create. Show all posts
Design Pattern (JAVA) : Singleton Pattern
Design patterns summarize proven solutions for typical object oriented programming problems and help to minimize the design effort and eliminate the common mistakes. To understand the necessity of design patterns, we can always look at the problems and begin by tackling it with alternative or brutal force methods, and learn to appreciate the beauty and implications of design patterns.
In many cases, we wish to maintain a single instance of certain class at run time, e.g., we may wish to keep one single connection to a specific database, or we wish to a have a single sequential number generator to avoid duplication.
We can approach the problem in a few ways, and let's analyze them one by one:
a) We can create a 'global' instance of the class, and let all clients use this instance for activities associated with the class. This is fine provided that every client knows about such arrangement and follow it rigidly and diligently. In other words, we are delegating part of the class design responsibility to the 'customers' of the class. This is a sub-optimal solution.
b) We can monitor and control the class instantiation inside the class definition; we could create a static class member which might be boolean or int, and let the class constructor check it before class creation; no class will be created if the check fails. Yes, this sounds logical and feasible. The next thing we need to consider is: what to do if the check fails? How does the client know about the class instantiation failure? Remember that constructor method does NOT return anything as normal method does. A simple solution would be to let the constructor method throw out an exception, and let the client check and handle the exceptions.
Okay, this looks better, but still a little bit troublesome, right?
c) Using static methods.
class PrintSpooler
{
static String str;
//a static class implementation of Singleton pattern
static public void set(String s)
{
str = s;
}
static public void print()
{
System.out.println(str);
}
}
//==============================
public class staticPrint
{
public static void main(String argv[])
{
PrintSpooler ps = new PrintSpooler();
ps.set("orginal?");
PrintSpooler ps2 = new PrintSpooler();
ps2.set("different?");
ps.print();
}
}
d) How about we make the constructor private, and force user to create an instance of the class using another normal member method? Yes, that is the deal.
class iSpooler
{
static boolean instance_flag = false; //true if 1 instance
private iSpooler() { }
//static Instance method returns one instance or null
static public iSpooler Instance()
{
if (! instance_flag)
{
instance_flag = true;
return new iSpooler(); //only callable from within
}
else
return null; //return no further instances
}
public void finalize()
{
instance_flag = false;
}
}
In many cases, we wish to maintain a single instance of certain class at run time, e.g., we may wish to keep one single connection to a specific database, or we wish to a have a single sequential number generator to avoid duplication.
We can approach the problem in a few ways, and let's analyze them one by one:
a) We can create a 'global' instance of the class, and let all clients use this instance for activities associated with the class. This is fine provided that every client knows about such arrangement and follow it rigidly and diligently. In other words, we are delegating part of the class design responsibility to the 'customers' of the class. This is a sub-optimal solution.
b) We can monitor and control the class instantiation inside the class definition; we could create a static class member which might be boolean or int, and let the class constructor check it before class creation; no class will be created if the check fails. Yes, this sounds logical and feasible. The next thing we need to consider is: what to do if the check fails? How does the client know about the class instantiation failure? Remember that constructor method does NOT return anything as normal method does. A simple solution would be to let the constructor method throw out an exception, and let the client check and handle the exceptions.
Okay, this looks better, but still a little bit troublesome, right?
c) Using static methods.
class PrintSpooler
{
static String str;
//a static class implementation of Singleton pattern
static public void set(String s)
{
str = s;
}
static public void print()
{
System.out.println(str);
}
}
//==============================
public class staticPrint
{
public static void main(String argv[])
{
PrintSpooler ps = new PrintSpooler();
ps.set("orginal?");
PrintSpooler ps2 = new PrintSpooler();
ps2.set("different?");
ps.print();
}
}
d) How about we make the constructor private, and force user to create an instance of the class using another normal member method? Yes, that is the deal.
class iSpooler
{
static boolean instance_flag = false; //true if 1 instance
private iSpooler() { }
//static Instance method returns one instance or null
static public iSpooler Instance()
{
if (! instance_flag)
{
instance_flag = true;
return new iSpooler(); //only callable from within
}
else
return null; //return no further instances
}
public void finalize()
{
instance_flag = false;
}
}
GUI design engineering
Many people view GUI(HMI) design as the cosmetic aspect of the underlying engineering products or problems; other people view this a serious engineering topic as part of the products/problems.
In a highly competitive business world where quality and customer satisfaction is ultimately emphasized, software is more appropriately addressed as service rather than product. Thus, software usability depends on both the 'quality' in a traditional sense, but also customer experience. However, very often than not, we are seeing people/company creating/upgrading products which prevent people from using it or loving it (you hate it, yet, you may still have to use it, :( ).
As a very intensive sofware user, observer, I wish to compile a check list as warning for all GUI engineers, including myself.
1) do not use out-dated technologies for the sake of compatibility; be a hero, lead the revolution! we should avoid creating software which we know will only survive a few months.
2) do not count on users to read and comprehand your thick mauals! let your software speak for itself. Use their language and sign, follow their thinking, and mimic their habits.
3) do not let user repetitively input information. And, you know what I am talking about. That is NOT called validation or security measure, it is called 'amnesia'. Always remember what the user has told you until they have logged out or timed out.
4) be intelligent. Try to make use of known information on the fly, and avoid asking stupid questions. (we do not ask NRIC number from a foreigner.)
5) always leave your user a choice. Customer is god! your god should be able to do whatever whenever they want. They should be able to quit, delete, save, roll back, un-subscribe, un-focus, etc anytime on any page.
6) allow user to copy n paste, including pictures and objects.
7) consider i18n, if you can not support it, at least do not let it ruin the running instance of your program. (There are many such cases in the web: when you switch the input method, the page hangs or browser suicides.)
8) consider error handling. that is one of the basics in software engineering. Testing cases are part of error handling design.)
9) do not display useless information. Exception stacks are only useful to programmers, do not let them run out of the curtain, and that just adds to the frustration over the awkward accident. if it is going to die inevitably, let it die silently and rest in peace.
*) last but not least, never assume your software is perfect. the most we can achieve is 99.9, and 100 is hallucination. Consider debugging and error logging devices seriously ever since the design stage. Software which does not allow debugging and error logging can hardly achieve a passing grade.
In a highly competitive business world where quality and customer satisfaction is ultimately emphasized, software is more appropriately addressed as service rather than product. Thus, software usability depends on both the 'quality' in a traditional sense, but also customer experience. However, very often than not, we are seeing people/company creating/upgrading products which prevent people from using it or loving it (you hate it, yet, you may still have to use it, :( ).
As a very intensive sofware user, observer, I wish to compile a check list as warning for all GUI engineers, including myself.
1) do not use out-dated technologies for the sake of compatibility; be a hero, lead the revolution! we should avoid creating software which we know will only survive a few months.
2) do not count on users to read and comprehand your thick mauals! let your software speak for itself. Use their language and sign, follow their thinking, and mimic their habits.
3) do not let user repetitively input information. And, you know what I am talking about. That is NOT called validation or security measure, it is called 'amnesia'. Always remember what the user has told you until they have logged out or timed out.
4) be intelligent. Try to make use of known information on the fly, and avoid asking stupid questions. (we do not ask NRIC number from a foreigner.)
5) always leave your user a choice. Customer is god! your god should be able to do whatever whenever they want. They should be able to quit, delete, save, roll back, un-subscribe, un-focus, etc anytime on any page.
6) allow user to copy n paste, including pictures and objects.
7) consider i18n, if you can not support it, at least do not let it ruin the running instance of your program. (There are many such cases in the web: when you switch the input method, the page hangs or browser suicides.)
8) consider error handling. that is one of the basics in software engineering. Testing cases are part of error handling design.)
9) do not display useless information. Exception stacks are only useful to programmers, do not let them run out of the curtain, and that just adds to the frustration over the awkward accident. if it is going to die inevitably, let it die silently and rest in peace.
*) last but not least, never assume your software is perfect. the most we can achieve is 99.9, and 100 is hallucination. Consider debugging and error logging devices seriously ever since the design stage. Software which does not allow debugging and error logging can hardly achieve a passing grade.
Why SWT? Why not SWING? - (1)
Well, this is a hard question. Do not mistake me, neither of them is better than the other. I have been using SWING for more than three years, and SWING is perfectly designed to embrace the concept of MVC (Model-View-Control). I love it.
In Java paradigm, SWING is considered a RI (reference implementation) for Java graphical specification. Yes, I believe most people will equal SWING and Java GUI library, but, that is not totally true. SWT is another implementation from IBM. I will try to touch a bit on the difference.
Java boasts its cross-platform capability of "write once, compile once, and run everywhere". The secret and cost is a virtual machine(VM) residing on every single OS species to run these compiled byte codes. SWING is part of the standard library implementation. The virtual machine will try to render every object you intended and coded on its own effort (without the help of OS). Well, this ensures the same graphics appears on different OSes (if you code wisely), but it hurts the runtime performance. This is even more sketchy in early versions of Sun JDK release. IBM has tried to tackle this problem from a fundamentally 'un-java' approach. SWT leverages the strength of MS Windows API, and let the windows draw whenever possible, and let Java draw whenelse. There are significant improvement in speed, but it becomes partially 'native'. While, you may already realized, is it still Java? emmm, that is a good question. But the fact is, SWT implementation is not bad, and it has quite a lot of users.
to be continued...
In Java paradigm, SWING is considered a RI (reference implementation) for Java graphical specification. Yes, I believe most people will equal SWING and Java GUI library, but, that is not totally true. SWT is another implementation from IBM. I will try to touch a bit on the difference.
Java boasts its cross-platform capability of "write once, compile once, and run everywhere". The secret and cost is a virtual machine(VM) residing on every single OS species to run these compiled byte codes. SWING is part of the standard library implementation. The virtual machine will try to render every object you intended and coded on its own effort (without the help of OS). Well, this ensures the same graphics appears on different OSes (if you code wisely), but it hurts the runtime performance. This is even more sketchy in early versions of Sun JDK release. IBM has tried to tackle this problem from a fundamentally 'un-java' approach. SWT leverages the strength of MS Windows API, and let the windows draw whenever possible, and let Java draw whenelse. There are significant improvement in speed, but it becomes partially 'native'. While, you may already realized, is it still Java? emmm, that is a good question. But the fact is, SWT implementation is not bad, and it has quite a lot of users.
to be continued...
MiniCAD -- a stand alone module for EMC simulation tool
This is something I developed during my first job. At the time, I was expected to enhance and expand the functionality of an existing GUI-based EMC simulation package.
The tool is capable of importing standard geometry data (meshed or un-meshed), collecting user simulation input, invoking simulation engine, and process simulation output.
The next phase of the project was to add in a simple CAD like module, which enables users to create customized geometry, and generate the mesh all under-one-roof.
For ease of tuning, I started to create a stand-alone module which allows to user to input some really really simple geometry. I also implemented some basic graphics control, like zoom-in, zoom-out and mouse-rotation.
Enabled by an open source package, the miniCAD can also create some surface meshing of the graphics. See...
The tool is capable of importing standard geometry data (meshed or un-meshed), collecting user simulation input, invoking simulation engine, and process simulation output.
The next phase of the project was to add in a simple CAD like module, which enables users to create customized geometry, and generate the mesh all under-one-roof.
For ease of tuning, I started to create a stand-alone module which allows to user to input some really really simple geometry. I also implemented some basic graphics control, like zoom-in, zoom-out and mouse-rotation.
Enabled by an open source package, the miniCAD can also create some surface meshing of the graphics. See...
FlowViewer -- By the engineer, For the engineer
My second job is a test software engineer position in a semiconductor testing firm. It is quite shocking to see how XML was maximizingly utilized in the testing programs. It is so heavily 'abused' that at the first look, we may think testing programs are XML programs (they are actually Java programs). XML is used to describe not only how these test are configured, but also in what sequence they are executed. A complete sapphire ATE program employs hundreds of XMLs, and it is really a headache to transverse these files to search for certain information. People have to be very sophisticated about how these files are organized, and spend a lot of time to trace certain information by opening many files in the file explorer.
I believe that a graphical based program analyzer and viewer could be very helpful. The application shall be able to load all these files in memory, and display them graphically in a organized and user-friendly fashion. User can then browse the test execution flow with a few mouse clicks, an find particular test information by a very fast memory-based search.
A little background to catch up here. The ATE tester software platform comes with a powerful (and also tricky) GUI based interface (namely, XTOS) which are used to load, run, configure, debug and log all the tests. Everything I am going to implement is already pretty encapsulated in this software suite. I am re-invent the wheels because of several considerations. Most importantly, XTOS is heavily coupled with tester hardware, which is a piece of extremely expensive (million $) hardware which we can not afford to have many. These testers are always shared by production line and we engineers, and we are always in the situation to struggle for more tester time. So if we can simulate the program by software, we saves a lot of hardware resources(and thus $!!!). Another killing factor is that, in real test setup, XTOS will try to load huge amount of test data, which takes about 1-2 hours waiting time. To properly view the test programs flow and setup, these data are not necessarily to be loaded. Last but not least, XTOS is more like a propriety software, and we are unable and also not supposed to modify its behavior and outlook to better fit our needs. So, I think it worthes the effort to create our own.
What FlowViewer is?
Flow Viewer has three functional blocks in current release:
** Test flow extraction and browse
** Test flow validation
** XML search, trace and highlight
What it is not?
*Flow Viewer is NOT part of TP
*Flow Viewer is NOT part of XTOS
*Flow Viewer is NOT a TP editor
*Flow Viewer is NOT capable to corrupt your TP
Flow Viewer is designed to be a convenient toolbox for TP owners/Test engineers.
*Flow Viewer is built on
*SWT/JFace graphics framework
*JDOM library
*XML validation Schema technology
*XPath enabled search technology
The project created a good opportunity for me to get acquainted with many XML related technologies, which I will write up to share in later posts.
ProgramManager: the first project I designed, implemented, and successfully marketed (for free)
Program manager is designed to work with Jobtool for easy repository and access of current production program revision, path, and invocation command. So, developers are reminded that any modification or addition of features to PM/Jobtool must ensure proper interface with Jobtool/PM.
PM is a GUI program which reads the program list file, parses the program information, and renders programs and program descriptions as user friendly tree and tables. User may click on the program tree to browse relevant configurations in table format, and modify/add/delete programs by keyboard input.
External libraries
- JDOM.jar (to parse XML file to DOM structure)
- activation.jar (to support mail.jar)
- mail.jar (to support email function)
Implemented features:
*Graphical representation of program hierarchy
*Context sensitive program configuration display and modification
*Program expiry auto email notification
*Program list file write access grant
*User login session auto time out
*program list auto backup
PM is a GUI program which reads the program list file, parses the program information, and renders programs and program descriptions as user friendly tree and tables. User may click on the program tree to browse relevant configurations in table format, and modify/add/delete programs by keyboard input.
External libraries
- JDOM.jar (to parse XML file to DOM structure)
- activation.jar (to support mail.jar)
- mail.jar (to support email function)
Implemented features:
*Graphical representation of program hierarchy
*Context sensitive program configuration display and modification
*Program expiry auto email notification
*Program list file write access grant
*User login session auto time out
*program list auto backup
Subscribe to:
Posts (Atom)