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
