This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Generic being made specific

Posted by Harry Keller on March 13, 2001 at 10:18 AM

> > [...]
> > > I want to talk about when to solve the specific
> > > problem versus the general problem. My thought is
> > > that you should always lean towards solving the
> > > specific problem, unless your product is
> > > a library or component that is supposed to solve
> > > a generic problem for other programmers.

> > Interesting.

> > Just for the sake of the argument, let me throw in
> > 3 (not really well-thought-out ;-) ) thoughts that,
> > IMO, point to the opposite, i.e. "by default, do it generically":

> > a) Probably you are familiar with Kernighan/Ritchie's classic
> > Programming in C, where they quite forcefully argue more than once
> > that one should think, design, and code as generic as possible.
> > [I know - that's not a valid argument, because it is "citing
> > a guru to intimidate you" - but I think it's worth to think
> > about the effect that this opinion has had on the development
> > of the "Unix culture"]
> >
> One of the oldest, most crinkled books on my shelf. I flipped thorugh
> it a bit last night, but wasn't able to find any of those spots you
> refer to. It has been so long since I went through that book, I don't
> remember where to look for their programming philosophy.

> > b) I do have a general rule of the thumb that is about:

> > - if you do/use/... something once, make it dirty
> > - if you do/use/need/... it a second time, you will need/use/... it very often -
> > hence you should make it generic.

> > c) Orthogonal (i.e., generic) designs allow users to more easily
> > use a system in ways the implementor did not expect. Together with
> > the axiom "Users will use a system in novel and unexpected ways",
> > this points strongly to a generic design for software: Make everything
> > scriptable; make everything programmable; make everything open so new
> > systems with (at least slightly) modified behavior can be "derived"
> > from the present system; etc.
> >
> > Ok. However, now, after I have thrown around with enough intelligent
> > top-level unconcrete ponderings about the only rightful attitude, which
> > is "think generically, and do so", I admit that in many cases (a) I do
> > not know how to make a class, subsystem, tool, etc. generic; and (b) even if
> > I know it, it is mostly a quite expensive endeavour, where either I or my
> > project manager (who controls the time=money) or we both quickly runs out
> > of patience.
> > So, hard real life forces us to keep to painful specific solutions most of the
> > time, instead of flying on the clouds of the real generic solutions to
> > every- and anything.
> >
> Alas, I think I made my comment too generic. Allow me to be more, uh, specific.

> I'm not really thinking so much about generic versus specific in the realm of designing
> systems, but in designing classes, especially problem domain classes. By "generic," I'm
> thinking about adding stuff in to make the class more general purpose than you really need
> at the moment, either to make the class more reusable or more easily able to be adapted
> to changed requirements in the future.

> While the end goals of enhanced reusability and changeability are worthy goals, I think
> there are two drawbacks to leaning towards generic classes, both of which you kind of
> mentioned. One is that it is hard to predict the future, so all your extra work may
> not really help the next person to come along who needs to change the class. And
> second, it simply takes longer to make something more generic.

> As a manager, I'd be trying to keep the programmers I manage fairly
> focused on accomplishing the job at hand. (Though I wouldn't try to
> micro-manage their class designs, just try to get them to talk about this
> kind of issue and try to emphasize the importance of keeping focused.)

> But on the other hand, when it comes to data management classes (those
> classes that don't really map to anything in the problem domain, but rather
> just help you manage the application's data in one way or another), I'm
> more warm to trying to design a more general class. I think its good to
> try and think of this kind of class in generic terms (this is a semaphore,
> or this is a finite state machine) so it can be
> reused more easily. Yet I still think its important not to get too
> carried away on making the thing generic that one loses focus on getting
> the job at hand done in a timely manner.

> I guess what I like to see when I go in to maintain someone's code
> is easy to read, cohesive, decoupled classes and interfaces that are
> fairly well focused on the job that needed to be done at the time. Then I
> can go in and make the changes I need to make to meet the new
> requirements.

> But I'd sure be interested in hearing other people's opinions. What
> do they like to see when they have to go in to maintain someone else's
> code? Generic? Specific? To what extent? Under what conditions? Etc.

> > Nevertheless, in my heart I'm with Terence Parr, who wrote in the
> > foreword of his thesis (about ANTLR) something along the lines of
> > "Before I solve a problem once in five days, I rather spend five years
> > on designing a really generic solution, from which the specific one can
> > then be derived in just 5 seconds."
> >
> Yup. I've done that too on several occasions, though I never had the
> opportunity to take 5 years to do it. Sometimes it has worked out, other
> times it didn't. One time I used lex and yacc to build a tool that would
> generate C code of a database interface layer from the SQL definition of
> the database. After that, instead of editing the C code of the DB layer
> each time we changed the database, we could just regenerate it. Once I
> got the bugs out of the tool, which was easier than debugging hand-changes
> to the DB layer code, the generated code didn't have bugs. The tool only took
> me one day to create and debug, and it saved us lots of time over the
> years I was there. People still used it after I left as well, so that one
> was a success. Other times, however, it turned out that I should have
> just done the stuff by hand instead of trying to find some fancy way
> to automate it.

> bv

So interesting to see what happened to my short comment. My concern is people who take an already fairly generic class and make it more specific (less generic) rather than extending it.

The issue of how to build it in the first place has been well covered by the posts. Balance build time, debug time, and reuse likelihood. In any event, spend plenty of time documenting your code for the next poor soul who must use it -- even if only maintaining it.

HK