[Flashcoders] Implicit Setters: Is validation considered a good or bad 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 ___ 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] Implicit Setters: Is validation considered a good or bad OOP practice ?
> 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 ? (3) definitly. It's called "defensive programming". Try to have your API as much checked (type-wise and logical-wise) as possible. This will enforce your internal logic constraints and prevent faultly programs. For instance any other component of your application (an UI for example) will except your volume to be positive and not NaN so you cannot allow such values to be set. And you shouldn't ignore this error also since silently ignoring errors will make you and others lose hours of debugging when something goes wrong "damn ! why this f... volume does not get set" answer : because it's NaN Nicolas ___ 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] Implicit Setters: Is validation considered a good or bad OOP practice ?
so if it's a bad input, it cannot tell the object that is modifying the setter property that something went wrong. Not sure if it's the best practice, but if someone passes in a bad input to your setter, in AS3 you can throw errors, such as: public function set volume( val:Number ) { if ( val == bad_news ) { throw new Error( "Volume Class - set volume(): Bad value passed in [" + val+ "]" ); } } Scott On 9/25/06, Nicolas Cannasse <[EMAIL PROTECTED]> wrote: > 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 ? (3) definitly. It's called "defensive programming". Try to have your API as much checked (type-wise and logical-wise) as possible. This will enforce your internal logic constraints and prevent faultly programs. For instance any other component of your application (an UI for example) will except your volume to be positive and not NaN so you cannot allow such values to be set. And you shouldn't ignore this error also since silently ignoring errors will make you and others lose hours of debugging when something goes wrong "damn ! why this f... volume does not get set" answer : because it's NaN Nicolas ___ 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 -- : : ) Scott ___ 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] Implicit Setters: Is validation considered a good or bad OOP practice ?
"Not sure if it's the best practice, but if someone passes in a bad input to your setter, in AS3 you can throw errors, such as:" You can do the same thing in AS2, of course... Jim Kremens On 9/25/06, slangeberg <[EMAIL PROTECTED]> wrote: >so if it's a bad input, it cannot tell the object that is modifying the setter property that something went wrong. Not sure if it's the best practice, but if someone passes in a bad input to your setter, in AS3 you can throw errors, such as: public function set volume( val:Number ) { if ( val == bad_news ) { throw new Error( "Volume Class - set volume(): Bad value passed in [" + val+ "]" ); } } Scott On 9/25/06, Nicolas Cannasse <[EMAIL PROTECTED]> wrote: > > > 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 ? > > (3) definitly. > > It's called "defensive programming". Try to have your API as much > checked (type-wise and logical-wise) as possible. This will enforce your > internal logic constraints and prevent faultly programs. > > For instance any other component of your application (an UI for example) > will except your volume to be positive and not NaN so you cannot allow > such values to be set. > > And you shouldn't ignore this error also since silently ignoring errors > will make you and others lose hours of debugging when something goes wrong > > "damn ! why this f... volume does not get set" > answer : because it's NaN > > Nicolas > ___ > 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 > -- : : ) Scott ___ 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 -- Jim Kremens ___ 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