Interesting point.
My counter would be that at the age of 14, these kids already have a
good understanding of foo+bar (and knowing to days kids fubar as well.)
I am not trying to teach them arithmetic. I am interested in showing
them how arithmetic is used in the context of programming to accomplish
something worthwhile like adding up the age of 2 cats.
Fortunately the "+" operation maps pretty well into the vocabulary of
arithmetic so I would not expect students shown either example to
flounder on the "+" sign.
I really want to teach them the right way to represent cats as things
inside a computer and to manipulate these abstractions as easily or more
easily than they can manipulate realworld cats. And to be able to extend
this same approach to dogs, credit cards, photographs, etc.
Ron
Alan MacDougall wrote:
I don't think you need to call it procedural. Just call it the basic
building blocks that they will need for OOP (or procedural, for that
matter).
There's not that much difference, really, between OOP and procedural.
OOP
just encapsulates chunks of procedural code and its data.
This is the correct answer. OOP probably isn't a bad framework in
which to teach these things, but when you start teaching you may be
surprised by how many students have a hard time grasping concepts that
may seem simple to you, even as simple as the relationship between a
class and an instance. You will also see students who blur through the
work and get bored five minutes after each class starts... but they
aren't the ones we're worried about.
So rather than engage in an argument as to whether OOP or procedural
is "better", we're basically asking: Do the additional distractions of
OOP justify the payoff from learning it up front? If you're teaching
fellow geeks, then yes. If you're teaching people with a more casual
interest in programming, or (shudder) people who are required to take
the class, you may want to keep it script-simple. Compare:
var foo:Number = 1;
var bar:Number = 2;
trace(foo + bar);
vs.
class Cat
{
private var age:Number;
public function setAge(age:Number):Void {this.age = age;}
public function getAge():Number {return age;}
}
var whiskers:Cat = new Cat();
whiskers.setAge(1);
var patches:Cat = new Cat();
patches.setAge(2);
trace(whiskers.getAge() + patches.getAge());
Is it so unrealistic to suggest that the second example, while having
a pleasant real-world basis, involves many more steps and logical
leaps for an absolute beginner to understand?
Maybe this is a strawman... I guess you could start with how getters
and setters work in the first place, and use that to explain
functions/methods. It just seems like a bit too much drapery to start
out with.
_______________________________________________
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
_______________________________________________
Flashcoders@chattyfig.figleaf.com
To change your subscription options or search the archive:
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
Brought to you by Fig Leaf Software
Premier Authorized Adobe Consulting and Training
http://www.figleaf.com
http://training.figleaf.com
