|
|
Posted by Jim on 04/20/07 14:47
Hi Steve,
> | 2. Use __get and __set which I prefer the idea of from a user
> | interface point of view though I understand they take no notice of
> | member visibility.
>
> plus, the only get called when the caller makes reference to an interface
> that does NOT exist on your object. you cannot for instance, expect to run
> code that handles someone setting $obj->foo (which let's say is
> valid)...__set will only be called when someone tries $obj->Foo or
> $obj->fooo or any other misspelling. afaicr.
I would have something like a switch statement that made sure the
variables the user is trying to set are valid and runs the appropriate
private function to validate. For example, I might define
"description" as a property which will then exists in the switch list
in the __set function which will then in turn call set_description
which would carry out any validation and store the value in something
like _description. They only thing I really achieve by doing this is
avoiding the user having to call set and get functions, I think it's
worth it though.
> add_item could/would be the best place to add validation for $item, imo.
> however, you still can't protect $item from someone changing it's values
> after add_item has had it's way with it.
I have to disagree with that. It feels most confortable with me to do
validation in the Item object, since in my mind the logic and
behaviour of that object should be contained within itself rather than
creating a dependency on the component object. I'm open to persuation
though.
Thanks,
Jimmy.
Navigation:
[Reply to this message]
|