Re: Getting and Setting and best practise


"Jerry Stuckle" <jstucklex@xxxxxxxxxxxxx> wrote in message
news:yuadncQAZvYUeLXbnZ2dnUVZ_uejnZ2d@xxxxxxxxxxxxxx
| 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.


.

Relevant Pages

  • Re: Getting and Setting and best practise
    ... 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. ... his private setter could strongly type the param which would throw errors automatically in php if the param type didn't match. ... Validation also becomes ...
    (comp.lang.php)
  • RE: Running public IPs inside an RFC 1597 network
    ... > I'm running a typical Class C RFC 1597 network in my lab. ... know or care if we humans designate a subnet as public or private. ... is the absolute most general route there is for a machine. ... In a correctly configured system when you define an interface, ...
    (freebsd-questions)
  • Re: Object Oriented Content System - the idea
    ... Would probably be difficult to enforce this militant style in PHP. ... (It's java, but you probably don't have to know java to see what's going ... The advantage of keeping them private or protected has been to prevent using ... way of private inner class and interface) In PHP this typically means another ...
    (comp.lang.php)
  • Re: NAT troubleshooting
    ... I dont follow...which interface are you talking about? ... Private interface does ... You don't really Need that NIC for NAT to work. ... Ethernet adapter Local Area Connection: ...
    (microsoft.public.windows.server.networking)
  • Re: it is time to retire non-MIME MUAs
    ... Of of these days I'd have hack a private mailing list gateway into ... my news server). ... is not synonymous with "NNTP". ... the interface which delivers it doesn't matter. ...
    (comp.mail.misc)
Loading