donderdag 19 maart 2009

The Super Pattern of Order

The Super Pattern of Order

Humans like to order stuff. This is done by putting it somewhere where (we think) we can find it again. We have houses with rooms and closets with drawers. We have pockets, briefcases, safes, bank accounts, wallets, shelves, etcetera. Each location is meant to store something that fits in that location. Socks go in drawers, closets go in rooms and money goes in wallets. 

There is also a place for electronic documents. These locations often have metaphorical names like directory, folder, archive, “zip”, library or cabinet, to name a few.

Enables us to Locate Stuff

To find socks, I got to my closet where I open the drawer that contains my socks.  To find this document, I go to my computer, open my home folder and there it is. To find stuff we need a way to address it. My document can be addressed by three parameters. 1, the computer, 2 the folder and 3 the document name, or, in more abstract terms, the platform, the location and the name.

So that we can Manage it

What we want to do with electronic documents is to move them around. This document for example wants to leave my computer.  And it has, apparently, otherwise you would not be reading this. The reason for moving it around is that I want to get it from the initial location where it was developed to our QA department where it was reviewed to the final location where you found it (to tell you the truth, it did not go through QA).

Just to make Sure

I could just simply type the document, e-mail it to QA and let them forward it to the final place on the location where you found it. This model is based on trust and although I fully trust our QA department (hi guys!) I would want to have some control over the fact that my document completes its lifecycle (i.e. ends on its final destination). 

That we don't Lose it

And then, after I have received lots of comments, I want to maybe change it to mask the fact that I am not a native speaker and replace it on every final location with the new version.


maandag 16 maart 2009

Package naming convention in a mixed Java and OSGi world

The "standard" before OSGi was to move all internal stuff into *internal* packages.

IBM uses the *internal* approach in the ready for rational program:

Requirement: General 2.5
a)      Provide a list of non-public Eclipse interfaces and the methods used by your offering...

This means that IBM exports *internal* packages and asks for a rationale if you use one of its internal classes. This approach enables you to:
  1. point the programmers to the correct way to use the software
         OR 
  2. move the class out of internal and into the official API.
In OSGi, if you do not export a package, the programmer cannot access it. However, this breaks the important aspect that programmers sometimes use your classes in ways you did not envision. So you also export packages that could be interesting and only hide the absolutely non API packages.

However, if you want to use the jar outside of OSGi then there is no way of hiding the absolute non-API packages and also no way of recognizing that the package is off limits. 

Conclusion: there should be a new naming convention providing for three levels of package visibility. 
  1. API,  dom.organization.soandso
  2. Not intended to be API dom.organization.internal.soandso
  3. Absolutely not API dom.organization.private.soandso