So the things I was generating were business objects. I don’t plan for them to be anything special, just data holding beans. No logic methods. Think of them as Entity Beans with a XxxBeanHelper to handle the logic, much as you’d use a Stateless Session Bean.
Anyways, the ideas I’ve been pondering are on how to improve these guys. A while back I thought in terms of Primary and Secondary business objects. An idea that leaked into me from JDO. There are important business objects that you want to talk in terms of, such as a Company, PowerPlant or Person. And then there are secondary business objects, really just wrappers for connected data. Such as an Address, Country, or Currency. Obviously it depends on the system though, Currency could be pretty important in a banking application.
I realise now that there are also Container business objects, whose main role is to be a collection of another business object, but they have some special features.
Anyways. There would be interfaces for these different types. Primary and Secondary. They would fit the design process in that you would first draw up a Primary diagram,, and you’d assume you had secondary types available. So when deciding on a Person, I would just say, “Oh, and mailing address of type Address. “. Secondary types would make a good possibility for a company-wide pool of business object ideas.
The next idea is to stop null pointer deaths. Enforce the NULL pattern everywhere. Every business object’s attribute begins as a null pattern element. This means that for Address we have a city of type String and initial value [”"] and a country of type Country and initial value [new NullCountry()].
Then when an empty Address is returned to an AddressForm, the line:
address.getCountry().getISOCode() just returns an empty string. No NPE.
This is great for production, some users get some poor data, but generally things stay upright and they can move on or attempt to figure out what is causing it. For test it is bad as errors will slip through. So at test an overlay version of the Null pattern classes can be used which throws an Exception or prints loudly to the logging system. To make matters nicer, each business object would maintain its own NULL instance. So Address.country would really have an initial value of “Country.NULL”.
The idea may or may not work, but it’s kind of fun. I’ve used the Null pattern successfully all over the place, but never so fanatically as with these business objects. The generator is happily spewing them out too 
Deciding on the API for ‘indexed-properties’ was interesting. [aka Maps]. I ended up deciding to offer up the values via the entrySet method. I’ve never used this a lot due to the pain of extending it, but will give it a shot in a system and see how nice it is. At the very worst it will force me to entrySet-ify some extensions of mine. Or move to Jakarta Commons Collections.
It would be nice to create an SQL statement for each business object, then have the system automatically zap out DAO’s per object. Whether I’m using EJB, simple Java or C#, that would be useful. Not so good if I use an OR mapping tool though 
So the structure is currently looking like:
Primary –> Xxxx –> XxxxImpl ==> NullXxxx
With Xxxx.NULL = new NullXxxx.
I’ve not bothered with a Secondary interface at the moment. Primary has an ID, but I’m not sure what Secondary would have. Primary also has loosely-typed variables available through a map like interface. Another interesting experiment that moatas has been driving. It allows me to do something I’ve been talking about, adding temporary variables to a class. A nice way in which I can do hacks when I want to.
Hmm. Should be the subject of another blog. Creating systems with back doors, so that when you absolutely have to do it quick and hacky, there’s lots of possibilities. I’m sure there’s a large swell opposition from the do-it-right crowd
