August 27, 2005

Why encapsulate when you have polymorphism?

I've been wondering how much encapsulation we need when OOP gives us polymorphism. With polymorphism we can make our objects behave like objects from any other class, so why the zeal to hide how methods do their job? If we change implementations we can always write an adapter and remain faithful to our old API.

Time for a conceived example: Imagine a Controller class that sits between your frontend and model. Two methods in the Controller are loadResource() and saveResource(). Internally the Controller delegates calls to both methods to a ResourceManager like this:

public class Controller {

	private ResourceManager resourceManager;

	public Resource loadResource(String id) {
		return resourceManager.load(id);
	}

	public void saveResource(Resource r) {
		resourceManager.save(r);
	}

}

My point is that we might as well save our breath and write this:

public class Controller {

	private ResourceManager resourceManager;

	public ResourceManager getResourceManager()
		return resourceManager;
	}

}

With this the controller's clients call getResourceManager().load() instead of loadResource(). They know that a ResourceManager is involved. Did we break encapsulation? I don't really think so. Say two years later we need to migrate away from ResourceManager in favor of a similar but incompatible class ResourcePool. With a simple adapter we can make the new ResourcePool act as ResourceManager and keep the old Controller API:

public class Controller {

	private ResourcePool resourcePool;

	public ResourceManager getResourceManager() {
		return new ResourceManager() {
			public Resource load(String id) {
				return resourcePool.retrieve(id);
			}
			public Resource save(Resource r) {
				resourcePool.store(r);
			}
		};
	}

}

Exposing the ResourceManager has additional advantages: Clients of Controller can pass the ResourceManager on to other objects that need to load and save resources, but don't require other services from Controller. These objects will then only be coupled to the ResourceManager interface, even though it is actually the Controller acting behind the curtains.

Cheating yourself out of API breakage like this will not be applicable or appropriate in all situations. What you should keep in mind is that polymorphism gives you the freedom to not shield everything and still keep your interfaces stable when implementations change.

Comments (4)

August 24, 2005

Fear

Some of you people just scare me. I was just informed that, probably due to two recent entries, this site is now on the first result page of a Google search for "banana opening instructions".

I think I'll sleep with the lights on tonight.

Comments (2)

August 22, 2005

Fluff aside, how useful are tags?

I've been wondering how much I get out of tagging my bookmarks on del.icio.us. Tags are indeed helpful for temporarily grouping resources (e.g. for a research paper) or for gimmicks such as the quicklinks for this weblog (which are all my bookmarks with a particular tag). Being a geek and all I also enjoy the cozy feeling induced by diligently annotated data, which on its own has all the practical applications of a neatly trimmed Bonsai tree.

What I just don't see happening with my own tags is the emergence of a lasting vocabulary that would allow me to quickly retrieve existing bookmarks even years after they were entered. I often discover that I had filed a link under different tags than I thought, and end up searching my entire bookmarks Google-style, which always gets me what I'm looking for. When it comes to self-organization, braindead search beats tagging big time.

Taking a step back, the social aspect of tagging has much more mundane applications than an emergent "folksonomy". It's cool that I can subscribe to a particular person's links, which has nothing to do with tagging. I cannot imagine ever subscribing to a popular tag. It frightens me that Bloglines registers 63 subscribers to the del.icio.us tag programming. These people must have entirely too much time and a signal-to-noise threshold of miniscule proportions.

Another issue is that I see little incentive to care how other people would tag a link, or which tags are popular. I can tag a link with either programming or development. While programming is more widely used, why should I give a damn? This makes the whole prediction about evolving towards a common set of tags somewhat moot. Remember the fairy tale about how folksonomies would be like dirt tracks in the forest, where the best paths would pave themselves through the increasing number of people passionately agreeing with each other? Back in the days it sounded like such a neat analogy that we all believed it was going to happen. Two years later I no longer see why a public folksonomy would stabilize itself unless there is a huge incentive to being found under a popular tag.

Flickr might be a place where such an incentive exists. The difference between Flickr and del.icio.us is that at Flickr users tag their own content. Because everything on the internet is about either money or narcissism, everyone wants their product to be seen and there's a real reason to tag a photo beach rather than seaside.

Comments (3)

August 15, 2005

Someone buy this man a beer

Jason Kottke writes:

Perhaps this is impossible or unfair, but can we have a discussion about where technology and user experience on the web are headed without using any of the following words or concepts:

Ajax, web services, weblogs, Google, del.icio.us, Flickr, folksonomy, tags, hacks, podcasting, wikis, bottom-up, RSS, citizen journalism, mobile, TiVo, the Long Tail, and convergence.

He forgot "remix culture". I always wanted to write up a mega-rant about how buzzword echo chambers make me puke, but I can't seem to find words strong enough to convey the full extent of my hatred.

Comments (0)

August 10, 2005

Photoshop makes me feel stupid

For an application more ubiquitous than sand in the desert, I find it amazing how useless Photoshop is without additional training or reading material. For years Photoshop has successfully defended the honor of being the only program that makes me feel stupid every time I'm trying to use it.

There is nothing intuitive whatsoever about how to do foo in Photoshop. Want to see a layer and its mask at the same time? Hold ALT + Shift and left-click on the mask thumbnail. I'm embarrased to admit that I've yet to figure out how to draw a stroked pixel rectangle that's not filled, and yes, I couldn't make this stuff up if I wanted to.

How multi-step "undo" works in Photoshop is an experience of its own and should be personally lived through as such.

One of the most fascinating things about Photoshop is how a gazillon different (but essential) tool palettes are reliably blocking the exact spot you need to work on, with no way to dock them. You don't scroll in Photoshop, you move palettes. If you ever wondered why your designer keeps asking for a dual monitor setup, now you know. I also find it cute how Photoshop keeps denying the existence of my second mouse button, but maybe there's a chance this might change with Apple's recent step forward into 1987.

I had plans to write about the epic amounts of creativity the Photoshop team put into creating even more customly behaved UI widgets, but that's enough material for its own entry. Or its own book as far as I'm concerned.

Of course I'll keep using Photoshop because it's getting me such sharp results. At the price of my self-confidence and emotional stability of course, but sharp nonetheless.

P.S.: I've embedded a highly sophisticated text-virus into this entry which will blow up the computer of the first commenter mentioning "The GIMP". You've been warned.

Comments (6)

August 06, 2005

My number one newsreader request

Are you a newsreader vendor looking to take the syndication market by storm? Here's what you have to do: Be the first to ship a feature that monitors Apple.com's press info, and every time Apple announces or releases a new product the feature filters out any posts containing the words "Apple", "white", as well as any references to big cats or bearing Steve Job's children. Because it's such a fucking non-event every single time, and still every tool on the planet feels compelled to waste perfectly good bandwidth on the same boring coverage.

I'd so buy that.

Comments (0)

August 02, 2005

Disposing resources in SWT

Rumor has it that the SWT uses no garbage collection and forces you to dispose of widgets manually. If you've been avoiding SWT for this reason, know this:

  1. Disposing a widget automatically disposes its children, so closing a window will dispose all contained widgets as well.

  2. There are resources that do not have explicit parents, like fonts and colors. These must be disposed manually if you created them. However, most of the time you will use standard system colors and fonts which you don't have to dispose because they are managed by SWT.

  3. When you still need to create a custom resource (like an icon image), SWT has a class JFaceResources which offers a central registry for images, fonts and colors. This way you can reuse resources and don't need to worry about their later disposal.

One last piece of advice for SWT developers: If you absolutely want to dispose a resource manually (e.g. dispose a large image when its containing composite is disposed), do not override dispose() of the containing widget. The dispose() method will not be called if the containing parent is disposed. Instead add a DisposeListener and clean up there.

Comments (0)