The OO motivation behind using setter (and getters) is that it enforces the notion that nobody should be able to manipulate the state of the object except the object itself. If you follow this design principal as well as a handful of others, you will keep your code low-coupled, less likely to be spaghetti-like.
Today, your code compiles and looks great. However tommorow in the distant future, under circumstances where you would work in teams or your code gets in the hands of someone else, you cannot be certain they have the same mentality as you did when you coded it out. "Is it a good or bad practice to validate the value passed to the implicit setter method" ? Sure, why not. However setter methods, if I can remember, don't allow for a return so if it's a bad input, it cannot tell the object that is modifying the setter property that something went wrong. The 3 options you are presenting is a matter of unit testing. Can you anticipate that other programmers can break your code under certain circumstances by inputing certain kinds of parameters? If you have a set of test cases that will fulfil your requirements, then you will have to bulletproof your code to meet the degree of detail required to pass those tests. It's very easy to imagine how many ways something goes wrong but the real enemy for most programmers is time. Do you have the time to write validation code for every setter in every class? It's really your discretion. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of David Bellerive Sent: Monday, September 25, 2006 10:19 AM To: [email protected] Subject: [Flashcoders] Implicit Setters: Is validation considered a good orbad OOP practice ? I've been reading and learning about OO design & analysis for the past few months and I've just recently started applying what I've learned in my Flash projects ? Learning a new language (like AS3) is no biggie but learning how to code differently (from procedural to OOP) is the real challenge for me ! So here's my first OOP question : When using implicit setter methods (using the set modifier), is it considered a good or bad practice to validate the value passed to the implicit setter method ? For exemple, let's say I'm building a Flash Video Player component and I decide that, amongst others, it must have a volume component parameter which is a Number. In the implicit setter method for the volume, should I validate the value that is passed to this method and make sure it isn't null or undefined, it isn't NaN and that it isn't lower than 0 or higher than 100 ? Which of the following options is best : 1) Do not validate the value and let the user of my component set the volume to undesired values like null, undefined, NaN, -20, 973, etc. Here, the assignment will work as expected whatever the value is (unless it's of another datatype) but the component might fail at runtime since a volume obviously can never be NaN or null for exemple. 2) Validate the value and, if it is null, undefined or NaN, do nothing. If it is lower than 0, set it to 0. If it is higher than 100, set it to 100 ? Here, the assignment might not work as expected if the valus is undesired (like null or NaN for exemple) so this will prevent the component from failing at runtime but the user won't know that his assignment wasn't succesfull. 3) Validate the value and it it's an undesired value, throw an error ? Here, the component prevents the user from assigning and undesired value like NaN or undefined and the user is alerted of the failure at runtime provided that he used a try catch statement. What do you guys think ? __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ [email protected] 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 _______________________________________________ [email protected] 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
