Words I hate in software projects: “generic” April 11, 2008
Posted by Wille in Software Development.trackback
“Generic” is a word I have come to hate on software projects. Everytime I hear someone use the word “generic”, I pretty much instantly know that the person using the word is trying to solve a problem he can’t really define, because it is problem he doesn’t really have.
The same kind of bad smell and warning bells that go off should be sounded when someone uses the word “generic”, as when you find a class called ThisThatAndTheOtherManager in your codebase, because trying to do something in a “generic” way is a sign of the things I just mentioned: someone trying to overengineer a solution for vague problems that really don’t exist at the current time.
My firm opinion is that all solutions should be specific for the domain that they address - let me give an example: what does the generic ThisThatAndTheOtherManager really do? What problem does it solve? Is it clear to you? Probably not. On the other hand, what does the interface Comparable do? Even without knowing Java (from where the example comes), you can probably safely say that a Comparable can be compared with things, most likely other Comparable’s. That is a pretty specific, well defined task.
Sure, it doesn’t say a whole deal about how it compares itself to others, but that is where the beauty of object orientation comes in - you can solve a multitude of real, specific problems in the same domain, not by trying to create multipurpose objects that can be anything, but by creating encapsulated objects with tight, well defined responsibilities.
Any reusability comes not from being generic and multipurpose, but through having a small, well defined area of responsibility where the details of how that responsibility is carried out is hidden from the objects collaborators.
By combining objects with well defined responsibilities in different ways, you can achieve re-use because you have specific building blocks for your solution to a problem.
If you were building a house, wouldn’t you prefer to use nails and screws made for the purpose of putting up walls, rather than some blunt and generic “adhesive-put-things-together-thingy” that you didn’t quite know what it did or how it was supposed to do it?
So the next time you try to create a “generic” solution and solve problems you don’t really have or can’t really pin down, think twice about what you are doing. “Generic” is a swear word and an anti-pattern that merits a big smack over the back of your head if you use it.
Bad for you. Eg. I don’t want to write a repository class for each and every class I have that needs to persisted. I want a generic repository class that can persist any class I happen to have made persistable.
At least now I know I wouldn’t want to employ you. I guess you don’t like design patterns as well since they are generic solutions for similar problems.
You are misunderstanding my point:
I am writing about people writing classes with vague and undefined roles and purposes (ThisThatAndtheOtherManager).
Reusing code wherever possible you should definitely do though: for instance in my current project I’ve written a BeanServiceImpl, which is a DAO type object that will create, delete or update any type of java bean that is persistable with JPA..
I guess what you really wanted to say is that you don’t like low cohesion.
[...] code - part 2 April 23, 2008 Posted by Wille in Software Development. trackback A previous post raised a misunderstanding for one reader, thinking that I was somehow opposed to reuse. That could [...]