This saturday, my girlfriend and I went to Aalst, to visit the abandoned factory Du Parc. Du Parc was a brand of stockings that was manufactured in there, along with other things like socks and underwear.

Finding the entrance and getting in was pretty easy, and once we were in, we quickly started scouting the place (over time, we've come to realize that it's better to get a quick view of the whole place, so you can focus on those parts that are the nicest to shoot. It has happened before that we discover the most beautiful parts at the end of the day, when it is getting dark :).

A large part of the factory was blackened by a fire that had once raged in it (officials decided that the fire was no accident). There was still lots of semi-burned paperwork lying around. I must say, the traces of the fire produced a very nice color pallet. The production areas themselves were in no better state: leaking, collapsed and even missing roofs, rotten floors, oil spills, ...

There was one particular thing about the place: slogans were painted on most of the walls. The slogans themselves were incoherent messages, and ranged from (translated from dutch) "Ripped of - Thieves are pretty stupid" and "Students, you have no business here" to "And especially you two sluts should stay out of here".

Now we are used to seeing lots of graffiti in places like that, but this kind of painting was new for us :)

After a few hours of shooting, all of the sudden some man/woman (we're still not sure) who looked pretty much like an escaped psychiatric patient came to us,started asking what we were doing (shooting, duh :) and whether we had permission (of course we didn't :). We were not impressed and when we started asking whether he himself had permission, that person threatened to call the owner. Much to my surprise, a few seconds later, a fancy cell phone appeared, and he started "calling". I say "calling", as I can't tell for sure, since that person was gone as fast as he had come. I seriously doubt he actually called anyone (other than some imaginary friend :)

An hour later, in another part of the factory (it is a pretty large place), we ran into him again. He seemed to be surprised we were still there, once again mumbled something about the owner, and quickly disappeared again. But he had been active in that time: a small stairway that we had used early in the day, was now amateurishly barricaded with a cupboard and some fire extinguishers. It probably wouldn't have been able to slow down a 2 year old infant for longer than a few minutes :).

Once we were outside of the factory, to take some shots of the exterior walls, he even followed us from a distance, trying not to be spotted. Going out, we had also spotted another painted wall, with lots of text. It seemed to be one long incoherent rambling, of which I only remember fragments like "too much to the far right is dangerous", "illegal activities take place here", "porn inside this building". all very interesting :)

But still, it makes you wonder what really went on in that mind of his: is he really thinking he's battling with thieves? Doe she suffer from delusional paranoia? There's really nothing (left) in that building that could be of any interest to thieves. It's also pretty sad that people still live like this in our said-to-be wealthy country. That person probably needs help.

A shot taken that day:

Technorati Tags: urbex aalst

In my current project, we have a lot of immutable values (a side effect of the fact that we have a bitemporal domain¹², but that is a story for another time). We decided to actually enforce that immutability, so those values have no methods that mutate its state (a.k.a. setters). So all properties must be set at creation time using the constructor.

Now, some of these value classes have 10+ properties, so instantiating everything using the constructor isn't an attractive or readable option. Ideally, you'd use some kind of Builder Pattern to set those properties and create the actual instance once you're done setting them.

The only part that sucks about using Builders is that you have to code, test and maintain them. This is the part where dynamic proxies and code generation can come to the rescue. In the way I implemented this, we have three components in the solution:

• The immutable value class (OrganizationState is this example).
• Builder, an interface that defines a Builder, which is a class that knows how to build instances. This one should be extended for each concrete type you want to build, containing setters for each of the properties you want to set.
• BuilderFactory, a concrete class that can generate an implementation of the right Builder. This is done using JDK proxies.

Using those components looks like this:

The value class and its accompanying Builder interface:

public class OrganizationState implements Serializable, Reported {

	private Day foundedOn;
	private Day endedOn;
	private OrganizationEndReason endReason;
	private OrganizationType type;
	private EstablishmentType establishmentType;
	private KboStatus kboStatus;
	private Reporter authenticReporter;

	public OrganizationState(Day foundedOn, Day endedOn,
OrganizationEndReason endReason, OrganizationType type,
EstablishmentType establishmentType, KboStatus kboStatus, 
Reporter authenticReporter) {
		this.foundedOn = foundedOn;
...

public interface OrganizationStateBuilder extends
 Builder<OrganizationState> {
	void setFoundedOn(Day foundedOn);
	void setEndedOn(Day endedOn);
	void setEndReason(OrganizationEndReason endReason);
	void setType(OrganizationType type);
	void setEstablishmentType(EstablishmentType establishmentType);
	void setKboStatus(KboStatus kboStatus);
	void setAuthenticReporter(Reporter authenticReporter);
}

As you can see, we have 7 properties that need to be set. Using a constructor would lead to wieldy, unreadable code, especially when you have have lots of properties of the same type. The Builder interface itself looks like this:

public interface Builder<V> {

	/**
	 * Initialize the V instance being built by the builder
         * with given prototype instance.
	 * @param prototype
	 */
	void fromPrototype(V prototype);

	/**
	 * Build the product (a V instance) and return it.
	 */
	V build();
}

Now the client code for using a Builder looks like this:

 
//create an implementation of the OrganizationStateBuilder, using JDK proxies.
OrganizationStateBuilder builder = BuilderFactory.createBuilder(OrganizationStateBuilder.class);

//set the properties on the build, from is a TO that comes from the frontend.
builder.setAuthenticReporter(from.getOrganizationInfo().getAuthenticReporter());
builder.setFoundedOn(from.getOrganizationInfo().getStartDate());
builder.setEndedOn(from.getOrganizationInfo().getEndDate());
//set some more properties
...

//build the actual instance.
OrganizationState state = builder.build();

It is also possible to create an instance that takes its initial values from another instance. This is very especially useful if you only need to change a single property:

OrganizationState prototype = ....;
...
OrganizationStateBuilder builder = BuilderFactory.createBuilder(OrganizationStateBuilder.class);
builder.fromPrototype(prototype);

builder.setFoundedOn(Day.today());
//build the actual instance.
OrganizationState state = builder.build();

As you can see, this code look much easier on the eyes than the equivalent constructor based version would look. For the next part, we'll look at how the BuilderFactory is implemented, and I'll talk about the how this code is generated and tested.

meta-footnote-1=My colleague Erwin Vervaet made an excellent presentation at the Spring experience about this subject. meta-footnote-2=Martin Fowler has also written on the subject at http://www.martinfowler.com/eaaDev/timeNarrative.html.