Multi-threaded tests

Here's a little trick I used once to do some tests on threaded code: Wrap the thread library, and have the wrapper run one thread at a time (cooperative threading style, except yield() is implicit in all thread library calls) in a deterministic fashion. That makes the test repeatable and can detect any deadlocks that depend on which thread is scheduled at which yield() if you just re-run the test for all permutations of the scheduling order. On the minus side, you will never find any bugs that depend on scheduling another thread in the middle of something else (a side effect of the determinism you get from the cooperative threading), but my guess is that it's worth it in most cases.


topless objects

In connection to Magnus last post I mentioned some thoughts I have had for a long time regarding web applications and OO. Since I started in earnest doing web applications in java I have never felt really comfortable with the "common" design pattern. It kind of felt a lot better when doing Tapestry and Wicket but the unease never reall went away. In this post I'll try to put to words something that is still pretty vague in my mind so don't expect any kind of consistent story.

A common wisdom some years ago was that web applications was built in three tiers. The GUI layer with JSP, struts or some stuff like that. Som sort of controller layer or business logic layer, and finally a data access layer. The lower layers might be EJB or Spring. Whichever framework the layers usually are pretty isolated. Data is passed between them in simple structs. This usually results in a lot of mindless copying of data from one struct named 'somethingTO' into another struct called 'somethingFormBean'.
The GUI handlers, the controllers and the data access code are usually stateless, even if an ORM is used the state they hold are pretty simple. In other words, not a lot of object orientation going on.
The problem I think with this pattern is that it does not lend itself to reuse, it contains a lot of boilerplate copying of data transfer objects with no apparent gain. Sure, the layers are isolated from knowing implementation details of other layers. But any form of encapsulation has this goal so the tierd design pattern isn't unique in this.

One 'reaction' to this is naked objects (http://en.wikipedia.org/wiki/Naked_objects). Where basically the domain model is translated to classes. The business logic lives in the domain classes and operations on domain objects are exposed on the web. This sure sounds like a lot more OO-design applied to the web. I have no real experience working with this kind of framework so I might have everything backwards about them but I think the domain model here are related to business rules. Operating on entities like 'customer', 'books' or what nouns that sound relevant to the domain. I would like to name this the bottom-up approach. Desinging from the data layer upwards to the GUI layer.

The thing I would really like to see is a top-down approach to naked objects, maybe topless objects :-) That is, the domain model is not the nouns used to describe some data in a DB or back-end system. Rather I would suggest that the domain in web applications is request and response. So the basic class is request and response, each request is modelled regarding the input data. That is request and post parameters, session parameters and so on. The response is modelled with regards to the information that is to be published from the web server. I think this is more related to the interaction description on a web site, use cases or something similar. So you start with modelling the information that is to be sent to the server and what is to be retrieved. Similar interactions with respect to dataflow can for example be implemented as related classes.

So, relating it to Magnus post about lifecycles of objects. One could model the request/response as a state machine. The start state is the request coming in to the server. Proceeds through states like validating input, deciding where to go next, run business rules, retreive/update data, format for display, render html and then end. In this way the same state machine (might be the same implementing class) collects information and decides where to go. So a web framework would end up as something that has a repository of state machines that is triggered from the HttpServletRequest.

Yeah, I don't know. Perhaps that would lend itself to more OO practices in implementing web stuff. I guess I have to build it and see :-)

Some completely unrelated notices:
A remainder about writing JDK proxies and handling InvocationTargetException

Check out the fork of HiveMind called Gaderian