Site Sponsors:
New Project: SQLMate 
Well, here we code again ...

One might have noted that I am somewhat obsessed with SQLite at the moment ... and for good reason: From Android to Big Data, we are using SQLite on every 'conceivable.

So when it came time for me to mass-generate a few hundred tables & DAO's recently, I decided to write yet another source code generator.

See the related link (below) for a tad more information.


Cheers,

-Rn


[ add comment ] ( 242 views )   |  permalink  |  related link
Pay-As-You-Go -v- Global Initialization 
While easy to understand in Java, the opportunity to initialize data & classes prior to their use is a well known technique.

Here is a Java:


static ColorPair[] colors = null;

static {
List<ColorPair> array = new ArrayList<ColorPair>();
Color[] ccc = {
Color.BLACK,
Color.BLUE,
Color.CYAN,
Color.DARK_GRAY,
Color.GRAY,
Color.GREEN,
Color.LIGHT_GRAY,
Color.MAGENTA,
Color.ORANGE,
Color.PINK,
Color.RED,
Color.WHITE,
Color.YELLOW
};
for (Color a : ccc) {
for (Color b : ccc) {
if (a == b) {
continue;
}
array.add(new ColorPair(a, b));
}
}
colors = new ColorPair[array.size()];
array.toArray(colors);
}


Indeed, when we are guaranteed to use static content, then taking the time to pre-initialize objects is a common practice. Why would anyone want to do anything else?

Yet when calculating the total latency in pre-execution load times, on more than one occasion I have been found re-factoring static initializers so as to allow programs to be more responsive.

Pay As-You Go


Given that the above example has been defined as package-protected, surely it can be declared private.


private static ColorPair[] colors = null;


After so hiding the data structure, the very next thing to do might be to expose the structure with a more visible member function.


public static ColorPair[] GetDefaultColors() {
return colors;
}


Once so exposed, a far less costly initialization strategy can be created. -Specifically, rather than requiring colors to be pre-initialized, we can now pay-as-we-go by only allowing the initialization loop to run when the data are needed:


private static void init() {
List<ColorPair> array = new ArrayList<ColorPair>();
Color[] ccc = {
Color.BLACK,
Color.BLUE,
Color.CYAN,
Color.DARK_GRAY,
Color.GRAY,
Color.GREEN,
Color.LIGHT_GRAY,
Color.MAGENTA,
Color.ORANGE,
Color.PINK,
Color.RED,
Color.WHITE,
Color.YELLOW
};
for (Color a : ccc) {
for (Color b : ccc) {
if (a == b) {
continue;
}
array.add(new ColorPair(a, b));
}
}
colors = new ColorPair[array.size()];
array.toArray(colors);
}


Note in the above that the initialization still takes place as before, but not every time our program is loaded. Rather, we can "pay as we go" by allowing the structure to be initialized only if, as well as when, the data are required:


public static ColorPair[] GetDefaultColors() {
if(colors == null)
init();
return colors;
}


Conclusion


Whenever I find myself migrating a bit of code from a project into a support library the first thing I look for is an opportunity to convert any global / static initializers into a pay-as-you-go strategy. Of course, given that one of the first principles of good Object Oriented Design is Encapsulation, from a puritanical point of view many often find very little justification for doing anything else.

Enjoy the Journey!

-- Rn

[ add comment ] ( 332 views )   |  permalink

| 1 | 2 | 3 | 4 | 5 | 6 | Next> Last>>