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

Reply via email to