SDK

On Abstraction and Encapsulation

… or ‘OO is hurting the industry because encapsulation’

The ability to abstract is a powerful one. I have seen my share of uni-freshers. There are a million different kinds of students and they all have their different ways of understanding. Obviously, some are better than others, and some are worse.

The worse kind of students are those who cannot abstract. Of course all human beings can abstract to some degree or other, otherwise no one would be able to drive a modern motor vehicle, or eat a pie. But some students insist on ‘knowing all the details’ because ‘that’s how they understand things’.

To those students, the concept of an API is difficult to explain.

‘You call this method, and fun things happen.’
‘But how does it happen?’
‘You shouldn’t care.’
‘But I need to know!’

And there are sighs. They most likely won’t pass 101, or if they do get through, they’ll be miserable for the rest of the course, unless you’re a hot chick and have a full set of 14 geeky Asian guys to help you out with the assignments.

There are a couple of explanations that can be offered for this. Most people, even some experienced developers, tend to side with one explanation: they are bad at abstraction. Without it, you won’t get far.

I beg to differ.

The reason why they won’t do well is that they are asking clearly the wrong person. They should not be asking lab demonstrators, who in all their infinite (well, 2 extra years’ worth of) wisdom, have no clue about how that API works. They should be asking the professors, the writers of that API, internet forums, or read the documentation, whatever. The information is available, but not from the lab demonstrators who get paid 13 dollars an hour including tax.

Their weakness is lack of confidence that stops them from asking difficult questions to the proper authority, and laziness in their quest for information.

Look at the top students on the other hand. The chances are, they fully well know how their favourite APIs work underneath the covers. They probably know how the chips are manufactured, how gates are made, circuits are designed, machine code is executed, assembly code is written, compilers are architected, and so on, and so forth. All the way up, all the way down.

My point is this: abstraction is a powerful tool, but it’s only a tool and it’s only one of the tools.

To pretend that the students ’shouldn’t care’ about how an API works is at best ignorant and at worst, well, just ignorant. Of course they should fucking care, you know? Like Knuth or Dijkstra or someone rather really important once said in one of their immortal essays, although what we produce is computer code, we should never forget that what we’re really crafting is the behaviour of the machine. The runtime matters. It’s the thing that we’re trying to get the computer to do.

How else, other than finding out what your function call does, are you going to determine what the computer will do? Reading documentation is fine and dandy, but that guarantees neither the completeness nor the correctness.

You will never learn how to fix a car by reading the owner’s manual, or even the repair manual, or even the blueprints of the car straight from the manufacturer. You have to open it up. Take the wheels off. Lift the car from its axle. Pry open the diff. Feel how broken that bearing is. Shake it and see what sound it makes. That is how you learn how to fix something. That is how you learn _anything.

Furthering my point, I make this claim: Currently, the ‘abstraction’ is severely overrated, especially in OO- and component-oriented programming circles.

What they write is this: the blue button makes it go. The red one makes it go faster. Do not press them at the same time. That’s the extent of the 90% of the API documentation there are.

And they expect us to work with it. What if you want to make it go slower? The trick is to press the two buttons at the same time, except for in the next minor version update, pressing the both buttons at the same time makes it blow up, and you’re punished for using an undocumented feature.

‘We told you not to’, says the smug author. And we agree with him. All the OO people agree that this is the way it should happen. Don’t do things that you’re not told to.

But hang on a minute. Don’t you think that’s even slightly weird? Why such change in behaviour? Why did it make it go slower in the first version? What deficiency in the original design prompted the authors to make such changes? Wouldn’t you want to know? Wouldn’t you be curious?

Most of all, wouldn’t you be pissed off if it broke your app?

But no. We’re told it’s just like a contract between two entities. You keep to the words, and don’t do things that are not specified it in the contract, or there be consequences.

Bullshit, I say: in the real world, if pressing those two buttons made things go slower for more than 12 months, it would be in the de-facto go-slow-mode contract, which would be enforceable. The wordings of the contract itself be damned.

The proper way to make things would be to let people know why and how the things work. Abstract it, document it, that’s all fine, but do not hide how and why things happen. Craft every bit, every level of the application correctly, thoughtfully. Then let people see it. Let people see your fucking craftsmanship. If you ain’t got one, this is a very good time to get one.

This brings around me to the final point: although I started off this article by talking about abstraction, it’s not about abstraction as such. It’s about hiding behind it and thinking that kludge is OK as long as you stick to the contract, the API, the interface, whatever.

People don’t think in terms of contracts. They think in terms of behaviours, hows and whys. When you ring up your ISP, you don’t have the service contract in your mind. You want the internet to work, and you want them to keep quiet about your midget-porn download usage. Fuck the contract. Who gives a shit? Who even reads them? If they didn’t have the explicit midget-porn-secrecy clause in their contract, and if they spill the beans, you’d be furious, wouldn’t you?

So there. Be honest, write good code, let people see what’s going on. Do not hide behind the encapsulation. If you do, you’re a midget-porn lover.

.J