Abstraction Part One
Abstraction is a reduction of scope. When approaching a problem, we hopefully paint a large picture and quickly expand that picture into a series of finite steps. Much like computer instructions our tasks are finite and concrete*, whether those tasks are building an application or typing the letter ‘f’. Abstraction comes in at the optimal instruction scope and flattens some of the necessary steps, reducing the overall scope. For example: while typing the letter ‘f’ has an extremely small scope, and building an application is scopious, abstracting away an IPC** method has just about the correct scope.
Abstraction helps me to build a support structure for my code. It helps me to reuse things rather than rewrite them. And sometimes I don’t do it and I write something quick that I’ll later rewrite or throw away. When I do that I can hear a baby cry in the distance.
Next time I bring up abstraction I’ll produce some code. This is only an introduction.
* Humans persist on a looser timeline than computers and are known to eschew order rather than demand it.
** Inter-Process Communication. Many processes would have to talk to one central ear, for example. They’d all have to do it in the same way so you abstract and write the talking part once. Otherwise you might fat finger one process and later discover it talking to the central hand.

November 12th, 2008 at 4:18 pm
efse3×2gycm4pelh