RE: [Flashcoders] Property Access (was: Intro to OOP using ActionScript)
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
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
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
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