Robert works for an investment bank and has spent many years creating and maintaining trading systems. He knows far too much about low latency data systems and garbage collection than is good for anyone. If you find yourself in a pub with him then do NOT mention phrases like "mark and sweep" or "memory profiling" as you'll be stuck there for hours and, might, be forced to break an ashtray over your own head to get away from him.
The Neverending Abstraction
When do you stop making
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?
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?
Re: The Neverending Abstraction
The mantra I use to stop this happening in my own code and class designs is "Just because two objects share one or more fields, that in itself is not enough to make them part of the same inheritance hierarchy".
When I was a less experienced programmer and had had "code reuse" drilled into me as a benefit of OO, I would have gone down that route. Now I only introduce an inheritance relationship where it actually belongs based on sensible modelling, rather than just because the objects "look" similar.
Of course, I can't think of any more examples right now :-/
Re: The Neverending Abstraction
Robert, I tend to have a base class named Entity in my designs. It usually contains attributes and behavior all entity objects will share. Also, for items that are deletable, I might have a so-named marker interface.
I'd understand if you said there were too many, and/or they were poorly named. Can you explain why the Entity base class?
Re: The Neverending Abstraction
This sounds rather familiar! I remember when I started coding I always wanted to write the most generic re-usable thing in the world ever... As time went on I began to realise that I was not writing a closed source package. I was writing some code to do a job, and that the code (from my companies point of view) was open...
Now I am a great fan of the JAGNI principle (You Ain't Going to Need It). A rule of thumb I use is to only create a super class if there is a serious chance of actually putting some code in there. If you are going to end up with an 'empty' super class you have to seriously wonder if it is adding any value....
Tom
Now I am a great fan of the JAGNI principle (You Ain't Going to Need It). A rule of thumb I use is to only create a super class if there is a serious chance of actually putting some code in there. If you are going to end up with an 'empty' super class you have to seriously wonder if it is adding any value....
Tom
Re: The Neverending Abstraction
I was with you until you got to the legal identifiers. Don't know if you are aware of it or not but the example you cited is a recognized (and useful, IMHO) analysis pattern called the Party pattern where the super-class of Person and Organization is called "Party". The context is that a person or an organization can be party to a business transaction.
Re: The Neverending Abstraction
I'd personally (and this could turn into a religious argument to compete with emacs verses vi) see Party as an interface which defines the behaviour of being a party to a legal agreement rather than as a superclass with shared attributes.
This is subtly different to having a superclass of entity and trying to share/shoehorn all the attributes there.
