The Neverending Abstraction

Fri, 04 May 2007 13:00:34 GMT

A common issue I see is the temptation to solve every problem by introducing an extra layer of abstraction. Abstractions aren't a problem in themselves but I'm seeing situations where developers are trying to think of ever more bizarre situations (that either can't or won't occur) and then adding ever more levels of abstractions to take these into account.

An example would be where you start with a Customer object and it has a name field - pretty simple and common. Then someone points out that a Customer and Employee are both People so you have a Person superclass and move the name field to there. Still looks OK but then someone points out that companies have names too so we have an object above Person called Entity and move the name there.

Then the chaos starts. Someone else (not wanting to be outdone and wanting to prove they have elite OO skills) says that some virtual holding companies don't have names and instead only have company numbers, so the name itself is abstracted to be 'legalIdentifier'.

This leaves confused, maintenance programmers looking to populate the customer name field on a form with entity.getLegalIdentifier(). Is that their name, national security number, company ID etc? Who knows - it's not immediately obvious.

Having many interfaces that only contain one method is a symptom as are superclasses with names like the following: Entity, SystemObject, BusinessObject etc. Do you have any more examples?

Coding the Architecture - abstraction tag

The Neverending Abstraction