Painting your object-oriented door

The other day I was thinking about object orientation for some reason. Probably because I’d been working in Java a lot at the time and had also (re)read about hammer-building factory factories.

Anyway, I got to thinking, how do you paint a door in an object-oriented world? I mean, one’s first instinct would be to call door.paint(Color.Red) or something. But a self-painting door? What the…? And with a self-painting door, you can’t control how you want it painted. But what if the door’s implementor created a door.paint(…) method that only supports 3 different colours, and no patterns other than a straight, single-colour door? How would you feel about going down to the hardware store to pick up a door, but the instructions said “You may only paint this door a straight brown, white or green”. Well, I probably wouldn’t buy that door. Leastaways, I wouldn’t if I wanted something to coordinate with my orange-coloured house (note: my house isn’t actually coloured orange).

And you can’t just paint(door, RED). This is the Kingdom of the Nouns, after all. What else? Well, I suppose you could modify yourself to extend the Painter class, but we don’t support multiple inheritance so you’re going to be in trouble when you want to trim the hedge and find you don’t have room to inherit from Gardener.

me.paint(door, Color.Red)? Suddenly you’ve got a paint method sitting in the middle of whatever class we’re in (Person perhaps) – are we going to be adding trimGarden(garden.getPlant(hedge[0])), takeOutGarbage(When.Soon) or mow(lawn) soon? And if not, how are we going to get those details in?

No, you’d need to hire a DoorPainter.

Offer offer;
Door door=new Door(DoorTypes.Wood);
DoorPainter doorPainter;

do{
	doorPainter=PhoneBook.getDoorPainter();
	telephone.call(doorPainter);
	doorPainter.describeDoor(door);
	doorPainter.describePattern(DoorPainterStyles.Swirl);
	doorPainter.setColor(0, Color.Red);
	offer=doorPainter.getOffer();
	while(!me.isHappy(offer)){
		doorPainter.haggle(Calendar.NextTuesday, Expressions.LessThan, 160.0);
		try{
			offer=doorPainter.getOffer();
		}
		catch(WillNotGoAnyLowerException e){
			break;
		}
	}
} until(me.isHappy());
doorPainter.paint(Calendar.NextFriday, 250.0);
try{
	doorPainter.complain();
}
catch(NoAnswerException e){
	me.getGrumpy();
}

And then… the inevitable strikes. Where am I going to put this code? I think I’ve already decided I can’t put it in the Person class. Hmmmmm…. ah! I’ll just use a little NegotiationFactory.newNegotiation(Service.Paint, door.getClass());

Note: OK. I admit it. This is terrible design. At some point, you stop, think about it, and try to come up with something better, and even if it isn’t pure, it’ll work, and you don’t need to create half-a-dozen classes to paint a door.

What’s my point? I don’t know. I was bored (having finished my book) and on a bus, and suddenly felt inspired to write this on a piece of paper I had with me. I thought it was mildly amusing.

Maybe it’s a warning, but whether it’s a warning to make sure that one doesn’t get carried away and object-orient stupidly off into the sunset or to take an extra book if I’m near finished the last one, I couldn’t say.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: