RE: [Flashcoders] Property Access (was: Intro to OOP using ActionScript)

2007-08-22 Thread Kerry Thompson
Ron Wheeler wrote:
 
 Not addressing properties is a requirement of OOP otherwise you break
 encapsulation.

Allow me to politely disagree.

99% of the time, you are right. I just wrote a retirement calculator for
ING, entirely OOP, and there's not a public var to be found. Anywhere.

Let me back up a bit. The essence of OOP is defining a public interface.
Most of the time these will be public methods (functions). But there are
times when directly accessing a property is not only acceptable, but
preferred.

One example. I wrote a piece that simulated a planet moving through an
asteroid field. The planet exerted a gravitational pull on the asteroids--as
the planet approached an asteroid, the asteroid would start moving towards
the planet. The closer it got, the faster it would move towards the planet.

There were about a hundred asteroids, and they all needed to know the
current x and y of the planet, plus its slope (the direction in which it was
moving).

I made the x, y, and slope public properties, and accessed them directly.
The reason was simple: performance. Planet.slope was faster than
Planet.getSlope(). With a hundred asteroids accessing the property and doing
their own calculations, it really made a performance difference.

Where is the harm in that? How does that break encapsulation? The properties
I made public were part of the defined interface. The object knew it, and
the observers (the asteroids) knew it.

I might do it differently now--this was 7 years ago, and performance was
more of an issue than it is now. Still, it's a perfectly logical and solid
OOP implementation.

Cordially,

Kerry Thompson


___
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


Re: [Flashcoders] Property Access

2007-08-22 Thread Steven Sacks

I wouldn't even go so far as to say he's 99% right.  More like 33.3%.

Private properties with Public getters and setters is used for one of
three reasons.

1) You need to do adjust the value of the property when set or get, such
as applying limits (max value is 100 so if you pass 150, set it to 100),
or storing the value internally as something different and returning a
modified value (internally using .5, but the API accepts 50).

2) You need to update the class when a property is set or get.

3) You need protection against dummies.


#3 is what Ron is talking about here, because if you're not doing #1 or
#2, then you don't need getters and setters.

I use public properties when appropriate.  I only use getters and 
setters when I need to do something to the property prior to setting it 
(such as limits) or some kind of update to the class when the property 
changes.


There's such a thing as over-architecting.  OOP sacrifices speed for 
flexibility and scalability.  You shouldn't overdo it with unnecessary 
function calls for setting public properties.  It causes code bloat and 
your code doesn't perform as well.  I don't wrote code for the lowest 
common denominator.  I've got work to get done.


We're Flash developers, not C++ developers.  We can't bring down the 
operating system with a bad value.  Some of these safeguards are in 
place because lower-level languages can cause real damage.  The only 
thing that can happen in Flash is that particular swf might have 
problems.  You can't bring down a system by missetting a property in Flash.


According to Ron Wheeler, I'm a bad coder.  I respectfully disagree. :)

___
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


Re: [Flashcoders] Property Access

2007-08-22 Thread Ron Wheeler



Steven Sacks wrote:

I wouldn't even go so far as to say he's 99% right.  More like 33.3%.

Private properties with Public getters and setters is used for one of
three reasons.

1) You need to do adjust the value of the property when set or get, such
as applying limits (max value is 100 so if you pass 150, set it to 100),
or storing the value internally as something different and returning a
modified value (internally using .5, but the API accepts 50).

2) You need to update the class when a property is set or get.

3) You need protection against dummies.


4) You need protection from the customer changing his mind once you have 
finished. That is what I mean by robustness.
If you have to do 1) after you have got the first version running, now 
you have to search through all the code that references the class to see 
if it sets the property.


If you examine the ratio of dummies getting to program with my code  to 
customers that change their requirements, dummies are less of a concern.



#3 is what Ron is talking about here, because if you're not doing #1 or
#2, then you don't need getters and setters.

I use public properties when appropriate.  I only use getters and 
setters when I need to do something to the property prior to setting 
it (such as limits) or some kind of update to the class when the 
property changes.


There's such a thing as over-architecting.  OOP sacrifices speed for 
flexibility and scalability.  You shouldn't overdo it with unnecessary 
function calls for setting public properties.  It causes code bloat 
and your code doesn't perform as well.  I don't wrote code for the 
lowest common denominator.  I've got work to get done.
If your work has to maintained or used by others as a base, you have no 
control about who is going to do it.


We're Flash developers, not C++ developers.  We can't bring down the 
operating system with a bad value.  Some of these safeguards are in 
place because lower-level languages can cause real damage.  The only 
thing that can happen in Flash is that particular swf might have 
problems.  You can't bring down a system by missetting a property in 
Flash.
You can bring down an application that is critical for the business. I 
don't care what people do for their own amusement but if I am paying the 
bill, I want it done in a way that is robust and not going to embarrass 
the company or get us sued. Our Flash eLearning system (ALI) has run 
without problems for years at clients' sites.
How important to the client would it be if they had flown soldiers in 
from all across the country to take a course and the course would not 
work because of a change in the requirements that broke some other function?
Granted, it will not start a nuclear war but the chance of doing 
additional business will be damaged severely.


The ALI is not perfectly coded by any stretch but I tried to get it 
done, on schedule, in a way that does not require any maintenance. It 
has proven to be capable of being modified to meet new needs and ideas 
without breaking existing code.


According to Ron Wheeler, I'm a bad coder.  I respectfully disagree. :)
Disagreeing with me is not, in itself, evidence of much. If I was to 
hire you as a consultant, I would be careful about standards and design 
reviews.
Coding does not bother me as much as design. I would look for your 
interfaces definitions and your class structures.
I am sure that once we had a meeting of the minds, everything would be 
fine. I can be a bit flexible, if the case is well made.


Don't forget that this started out as a discussion about teach newbies. 
Not converting old farts.


Ron


___
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


Re: [Flashcoders] Property Access

2007-08-22 Thread Steven Sacks

 Don't forget that this started out as a discussion about teach newbies.
 Not converting old farts.

LOL!  Well played.
___
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