|
|
Posted by Jerry Stuckle on 04/20/07 18:01
Steve wrote:
> "Jerry Stuckle" <jstucklex@attglobal.net> wrote in message
> news:yuadncQAZvYUeLXbnZ2dnUVZ_uejnZ2d@comcast.com...
> | Jim wrote:
> | > Hi guys,
> | >
> | > I have an object which represents an "item" in a CMS "component" where
> | > an "item" in the most basic form just a field, and a "component" is
> | > effectively a table.
> | >
> | > "item" objects can be created and then added to "component" objects to
> | > build up the component definition.
> | >
> | > My dilemma comes in deciding how to read/write data to the "item"
> | > object.
> | >
> | > I figure I can either:
> | >
> | > 1. Use getters and setters (hate the idea of them though)
> |
> | But it's the right way to go. Among other things, it makes the code
> | much easier to maintain in the future.
>
> actually, no, it doesn't. he wants to use a switch in __set/__get and call
> the appropriate PRIVATE getter/setter. PLUS, in doing so, he'd have
> simplified the object's interface. there is NO difference affecting the
> maintainability or scaling of the object in the future.
>
> only problem is, __set/__get only works when a *non-existent*
> method/property is getted/setted.
>
> | > 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.
> |
> | You can do it - but now you have to validate the parameter - is it an
> | actual value?
>
> the parameter is always $value. all he'd have to do in his scenario is take
> the __set value as a variant/non-typed variable. his private setter could
> strongly type the param which would throw errors automatically in php if the
> param type didn't match.
>
> | And it will be harder to maintain in the future - more
> | code to worry about when you add/delete values. Validation also becomes
> | much more complicated.
>
> i'm not sure you follow what he's saying, otherwise you'd see that your
> 'preferred' getting/setting is identical (though less effective) to how he's
> wanting to implement __set/__get - which is only a middle-man between the
> scopes of public and private. validation still happens in the same
> place...getters/setters (your preference noted)...what changes is that HIS
> getters/setters would have PRIVATE scope and would run automatically and
> with LESS code for the developer and the end consumer. ex.,
>
> his implementation:
>
> $foo->bar = 'hello world';
> echo $foo->bar;
>
> yours:
>
> $foo->setBar('hello world');
> echo $foo->getBar();
>
> to me the consumer, i *prefer* the former. now i think you can imagine what
> the code for the class would be in both scenarios. i can spell that out for
> you too if needed. BOTH would have setBar() and getBar() however...which is
> why i can't see how you derive your 'preference' based on your point of
> contention for said opinion(s).
>
> | > 3. Pass all the required parameters to one function and do all the
> | > validation there - inflexible, unintuitive and more work in the long
> | > run in my opinion.
>
> again, the same goes here. and, i'll not flog a dead horse any more than i
> have to.
>
> | About the same as using __set, isn't it?
>
> obviously not. consumer get ONE interface to deal with in his scenario.
>
> | From the point of clarity, ability to later modify the code, etc., I
> | much prefer getters and setters. Sure it means you may have a lot of
> | functions - but there won't be the independence on other code you have
> | with other ways. It will probably be faster, also.
>
> again, he's not doing away with them. he makes them private and the built-in
> __set/__get takes over publically as the middle-man for the public
> interface. and, as __set/__get ARE built-in, nothing you could script will
> execute any faster. as for 'independence' (i think you mean loose coupling),
> __set/__get of the class passes params to the appropriate private
> getters/setters. since they are part of the same object, there is NOTHING to
> decouple.
>
> i hate to take the arrows from your quiver, but i just don't think you
> understand the post.
>
> finally, i must say again. __get/__set only execute from php when a
> non-existent interface is accessed. so, no worries jerry, we're still suck
> with public getters/setters...for now.
>
>
Oh, I understand exactly what he's saying. But I don't have my head up
my ass like you do.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
Navigation:
[Reply to this message]
|