I'm not entirely sure, and I do hope they will forgive me if I am wrong, but I have a feeling it was one of the great Meyers triplets who started the movement back in favour of freestanding functions. Nathan or Scott in all likelihood; it seems improbable that the dissident brother Bertrand would concern himself with a stylistic nuance in a computer language he affects to despise (though we are sure he loves it really!).
Received a bit of a rocket from the Dr Dobb, no less.
Whoever started it,
the word is now out, and the movement grows stronger by the hour. Freestanding
functions are the new templates! The humble
The venerable doctor is now retired, and lives in a home for tottering techies at the edge of town. He frightens away the kids that come to tease by shouting at them in VAX Modula-2.
I've got a spanking brand new PC.
When last week an innocent posted to the legendary Brainlobe of the week newsgroup suggesting a solution to the current puzzle that embodied the principal algorithm in a couple of methods, the hootings of mirth could be heard all the way across the comp.* groups. Member functions are still acceptable as accessors for the instance data; anything more is vulgarity.
However, the habits of a lifetime are not easily dropped, and the eponymous founder still keeps an eye on the old magazine and its webby satellites; dispatching curt, capitalised emails to those who fall below the mark. Mine reads
QUIT FOOLING. WHERE CODE?
It's not beige like yours. It's black and silver. It's sex on a stick.
Stated briefly, the argument goes like this. The methods of a class are inevitably tightly coupled to the format of the class's fields. But the work done by the class need not be. If the only code that can 'see' these fields is contained in the accessor methods, then the ties that bind have been eased. Change the representation of the data as much as you like; you have only to change the code in a few, known places.
It has a 1.7 GHz Pent 4 proc, half a gig of RAM, a bog-off hard disk and a DVD.
Thus encouraged, I thought I'd do a serious, bread-and-butter piece this time on a topic close to most of our hearts: C++ design. Or more properly '++C Design' as those like me, with a responsible attitude to the unnecessary creation of temporaries, prefer to call it.
It can bring up Visual C++ in about five seconds. Delphi's even quicker.
But where to put the
non-accessor member functions? If we allow them to retain membership of the
class, how do we know that they won't put sticky unauthorised fingers directly
into the data? One could make all the data fields
Yup, it's an 18" screen. Flat panel, naturally. Do they still make the other kind?
Naturally, the next idea was to find a baffling way to do this with generics and a shed load of angled brackets. However when we looked for the template expert he was poring over a 17-line compilation error message, following an unsuccessful attempt to use one of the more exotic STL algorithms. We don't expect him back for a while yet.
The mouse that came with it is black too, but I am not using that. I've got one of those new touchy feely ones. It vibrates.
Another item of housekeeping: it might prove a convenience to make a printout of this page before you start. It may well turn out that you will want to highlight the key sentences in fluorescent green with your Stablo Boss, and write 'So simple -- once it has been pointed out!!!' in the margin.
And it's got a blue LED on its bottom. No balls.
Then somebody said: why not just use standalone functions? Barring friendship, these guys never touch instance data anyway. Lets just move all the manipulation stuff out of the class. It's elegant. It's simple. Best of all, it's something the Java people can't do!
Java people --- come back! You will enjoy this. I promise that I'll put in something about the wretchedness of header files, and the confusion and danger caused by using pointers, just so that you can experience a pleasant frisson of schadenfreude.
The keyboard is black too. It has some extra keys. Press this one and Dell sends round a man to find out what you want. That one puts it into hibernate.
My contention is that there is an important flaw in this solution. It is this: how does one remember the names of these standalone functions? How does one avoid typing them? Elderly programmers such myself have grown to depend on that little box of method names that springs up when you hit the '.' key, whereas many coders born after 1980 don't even realise it is possible to enter a function name by hand.
The action is special. Every time you press a key, an angel in heaven gasps 'Meg Ryan!'
As a matter of course, I will be using all the vogue words. You know, the ones that look as though they will yield up their meanings when stared at in context, but in fact do not. 'Affordance' is a good example. It would be a sensible idea to get hold of the office copy of the Concise Oxford or Webster's and get its engine warmed up before the action starts. The dictionaries won't help with interpretation as these words aren't in them, but discovering this for yourself will help you maintain your confidence.
You can try it if you like. Go on.
The solution is the double pimpl idiom or gobstopper idiom or journey to the centre of the earth. As usual, the outer class is just a skeleton. All its functions defer to functions called on a private implementation pointer, which refers to a forward reference class. This middle class contains the implementations of all the methods. However -- and here is the clever bit -- it in turn defers to another class. It is this central class that actually contains the instance data.
The functions will
all be called 'foo()'
and 'bar()', the
templates 'T', the
classes 'A', '
Don't hit the space bar, fool. Try something that doesn't get used all the time, like Num Lock. Not that button; that's hiber
