|
|
|
| Authored by: greed on Saturday, May 05 2012 @ 02:37 PM EDT |
Abstraction is the problem.
It takes a certain mind-set to "see" in abstractions. I've read
claims that it's only about 20% of the population that can do so. Experience in
the software field for the last 25 years suggests that 20% might be aiming
high....
If you can't abstract, you can't program effectively.
If you're the type who spent Algebra class asking, "But what IS X? You
never told me what X is, how can I understand Y?" you're unlikely to be a
good programmer.
Procedural programming, what most people my age have seen in BASIC, is almost
like using a hammer to put in a screw. But it's the way most people like to
think:
10 Do this.
20 Do this next bit.
30 Do this other bit.
40 Do the last bit.
Functional and object oriented programming are very hard to get your mind
around. (Most people only see functional programming in makefiles; and most
people don't know that's what they're looking at. Editorial on the state of the
world's makefiles omitted....)
You can tell someone isn't really in the mind-set of object oriented programming
because they ask, "How do I do THING?"
If you're in the right mind-set, the question is, "How do I ask OBJECT to
do THING for me?"
It's like the difference between making coffee (roast beans, grind beans, put
grinds in filter, boil water, pour water through filter, wait until done, remove
filter, drink coffee) and ordering coffee (invoke the getCoffee method on the
CoffeeShop object... I mean ask the nice person behind the counter for a
"medium black to go".)
I'm not sure abstraction can be taught. Or, at least, taught directly. It's
not like "loops"; the first time I tried to play music with a
Commodore 64, I simply wrote dozens of "POKE" statements to start each
tone, and some sort of delay (forget how I did that now) for the duration. Hey,
I was 11, I knew about FOR...NEXT, but READ and DATA were still in my future.
An hour in my future--when I showed someone older the program.
Not that I'm claiming to be brilliant. My OO coding style tends to start with a
rough-in of the objects, but a lot of brute-force code. As I figure out what
I'm doing, the brute-force stuff gets stripped out and replaced with something
sensible.
(Or, more likely, the proof-of-concept kludge goes live....)
Object oriented programming works best when you try and keep track of as little
as possible: Don't worry about how many paws the dog has, let the Dog object do
that. Don't worry about the tires, let the Car object manage them.
People are taught to track and control everything, it seems to me. And that's
the opposite of what you want: you really want to push as much of the tracking
and control into the objects as you can.
[ Reply to This | Parent | # ]
|
|
|
|
|
