Ian Thomas wrote:
In reply to Steven:
- Firstly, Wikipedia isn't a great source to quote. :-D
- Secondly, OOP as a style has basic stuff, and it has advanced stuff. I'm
not saying teach inheritance and polymorphism on day 1, I'm saying teach
that objects have properties (and then objects have methods). Not
necessarily because it's _better_ than procedural (we could argue that
forever) but because _almost all day-to-day programming languages that the
students will encounter will involve objects, properties and methods_.
In reply to Alan:
Your first example applies equally to OOP or procedural - it's a code
snippet, not a coding style.
Your second example is overcomplicated - why teach getters and setters from
the word go when a property (public var age:Number;) is far simpler/more
obvious? Yes, getters and setters are part of the OOP paradigm, but not a
requirement.
That was my example. You teach people the right way to do it so that
they never consider addressing a property directly. It may look easier
but someday, it will break your code in a way that will cause you a lot
of grief. There are good reasons why it is not done.
Not addressing properties is a requirement of OOP otherwise you break
encapsulation.
When a person is first starting out, they will not question whether it
is easier or harder. It just is.None of my test frameworks would ever
address a property directly. I would not even mention the possibility of
doing such a silly thing.
If the discussion ever comes up, I would defer it until after the first
6 weeks and then use it to discuss the reasons why encapsulation is a
"good thing" and show why directly addressing properties is inherently evil.
It is also a good introduction into a discussion about programming to
interfaces which I also would have taught from day one. Not as a topic
but as a way to specify coding exercises. Give them the interface and
the program to test the class and ask them to create the class. Do not
explain why, just let them have the freedom of naming variables and
programming methods as long as it works with the interface.
From reviewing and discussing each other's code, they would already
know that the properties of a given class may vary from person to person
even if the Class is perfectly correct, the variable names follow
standards and the Class satisfies the interface. They would already know
that trying to guess property names for a class is impossible and that
if you switched from one person's implementation to another, your
program could fail if you have tried to use properties directly.
They would have seen that the test frameworks given for each exercise
were not implementation dependent..
Ron
Ian
On 8/21/07, Alan MacDougall <[EMAIL PROTECTED]> wrote:
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:
_______________________________________________
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
