Mutimedia authoring tools have been "object oriented" for a long time
because "interactive" multimedia requires a reasonable way to handle
user-driven events. So there is no way to avoid working with objects.
But what does it mean to "start with OOP"? or not "start with OOP?" I
have a lot of sympathy for Steven's first point. Students who are new to
programming have a lot to learn that we take for granted. It is an
interesting problem: where to start so that students can learn in
managable increments and can enjoy the process by having lots of
opportunities to experiment with things that interest them.
If you have them on your bookshelf have a look at the first chapter of
Colin Moock's Essential ActionScript 3.0 and chapter 1 of his
ActionScript for Flash MX. Now ask yourself which chapter you would
prefer to start teaching students in high school with? In chapter 1 of
ActionScript for Flash MX students see the basics of what some might
call procedural programing, such as expressions and statements. They
also read about handling events and scripting objects (Buttons and
TextFields). By the end of the chapter they can build and experiment
with a simple quiz. So after less than 40 pages they have something they
can work with that does something. That's important.
On the hand, Essential ActionScript 3 spends roughly 40 pages on
packages, classes, objects, constructors, and other things. It takes
about six chapters before you have much code you can really play with
that has any impact on the user. (By the way, I'm not knocking Colin's
books. They are brilliantly written and I plan on using the AS3 book to
teach with next term.) Six chapters is alot to impose on high school
students in the first week or two when you want to get them to start off
doing something interesting.
So what does it mean to start with OOP? My personal approach is to delay
detailed teaching of packages, classes, inheritance, and so on. I
usually start with creating classes that can be associated with
movieclips or sprites in the library. I show students how to write
methods that give sprites new behaviours. Writing individual methods
involves "procedural" coding in response to events. Movement, drag and
drop, hit detection etc. Then I provide them with enough scaffolding
code to build something like a simple game. As the course progresses
they write code that provide sprites with more complex behaviours and
enhance games to, keep scores, add difficulty for the user, and add
levels. Along the way they learn about objects, packages, classes and
subclasses. I make sure they write nearly all their code in class files
from beginning to end.
In short I think you get a lot more mileage in the early going of a
class by providing examples and "scaffolding" that students can start
experimenting with early and parcel out higher-level object-oriented
programming and design theory as you go. In some ways AS 2 and
especially AS 3 make it harder for students to dive in quickly. But with
a little care and good examples its possible to lower the barrier to
experimentation - which I think is the essential thing.
Also, maybe its worth saying that I've seen the results of too much
theory up front on first year computer science students. Many are lost
by the approach. They are unsure what classes to create and what code to
put in each method to solve a problem. At any rate the essential thing
is to start where you students are and not where you want them to be.
Start with what they find interesting and not just what you find
interesting.
Yours truly,
-Brian
Ron Wheeler wrote:
What is a "subroutine"? Not used in this millennium. Seems to be a
concept from the distant past.
Start with OOP. We did not get here by accident.
It is easier. It is less prone to errors. It makes your coding
examples much smaller and much easier to grasp.
Their code exists in a small context. You can write the test programs
to get them started and let the students start by programming simple
classes that compile on their own and can be incorporated into your
test environment which they do not have to deal with until you are
ready to show them the object that uses their simple class.
Define the interface that their code must implement (might as well get
them used to programming to an interface), let them extend your
interface.
Show them how the interface is the "contract" between the user and the
class.
If you give them the interface class with lots of comments about the
functionality required for each method, you have the description of
the assignment.
Ron
Johannes Nel wrote:
i think teaching someone OOP from the begining is not a bad idea, you
are
still teching them to code but around classes. you do not need to
introduce
more advanced concepts until later. the best free book i think is
thinking
in java by bruce eckel and should be easily adaptable for your needs.
i also think as3 is a good place to start, you would be equipping
them with
a better language while still allowing them to do graphics. those who
want
to learn more coding will slot easier into languages like java, c# etc.
On 8/20/07, Ricky Bacon <[EMAIL PROTECTED]> wrote:
Steven Sacks wrote:
I think you should consider teaching programming basics, focusing on
clean code, best practices, naming conventions, etc. and touch on OOP
towards the end. The people who are most interested will seek out
more
information, but I think you will lose people if you try to teach OOP
concepts right out the gate before they even know how to iterate
through
an Array, or before they know what a subroutine is.
LISP? Just sayin...
-Ricky
_______________________________________________
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
--
______________________________________________________________________
Brian Lesser
Assistant Director, Application Development and Integration
Computing and Communications Services
Ryerson University
350 Victoria St.
Toronto, Ontario Phone: (416) 979-5000 ext. 6835
M5B 2K3 Fax: (416) 979-5220
Office: POD?? E-mail: [EMAIL PROTECTED]
(Enter through LB99) Web: http://www.ryerson.ca/~blesser
______________________________________________________________________
_______________________________________________
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
