SitePoint Sponsor

User Tag List

Results 1 to 9 of 9
  1. #1
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)

    Using set/get methods vs just accessing properties

    Hi,

    I couldn't find anything on this, probably because I dont have a clue what to search for!

    Can someone please explain why, in a class's method, I should use a seperate method like setSomething() to set/edit a class's property rather than accessing the property directly. For example, why use:
    PHP Code:
    $this->addErrorMessage($msg); 
    ...instead of just:
    PHP Code:
    $this->errorMessages[] = $msg
    ?

    Mike
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  2. #2
    SitePoint Addict
    Join Date
    Aug 2007
    Posts
    365
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    If the varible doesn't have to be an specific type and no restrictions on getting and setting I use $object->value

    Otherwise I use $object->setValue( $value );

  3. #3
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    It's about being explicit about the interface. With direct property access, it is hard to find out where the change was made. If you need to change your code, it's rather hard to localise all the places, where the property is used from. Another benefit of accessors (As getter/setters are called), is that you can stuff additional code in there, to execute when called. With a getter, you might implement lazy-loading and cache the result, without the caller knowing about it. With setters, you might implement logging, validation an so on. Even if you don't need this immediately, if you use accessors from the beginning, it's easy to add in later, since you don't have to change the interface.

    More generally, whenever an object needs access to another object's properties, it is a sign of badly factored code. In object oriented code, you should strive to keep functionality together with the data upon which it acts. If you do so, you'll find that you may not even need the accessor in the first place, and can then make the property entirely private.

  4. #4
    SitePoint Evangelist AlienDev's Avatar
    Join Date
    Feb 2007
    Location
    UK
    Posts
    591
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Thanks for the perfect reply, kyberfabrikken. That explained exactly what I was confused about.
    Me on StackOverflow | Blog & personal website.

    I mostly use: PHP, Java, JavaScript, Android.

  5. #5
    SitePoint Evangelist
    Join Date
    Mar 2005
    Posts
    421
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    You may what to read an interesting article on the subject by java guru Allen Holub, in an article he calls Getters and Setters are evil. Don't necessarily agree, but an interesting read anyway.

    getters and setters are evil.

    It's also in his book, Holub on Patterns.

  6. #6
    SitePoint Addict
    Join Date
    Sep 2006
    Posts
    232
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    I think what Allen Holub is trying to say is that getters and setters accessors are not evil by nature, but they can turn evil if you add them without any clear justification.

    And he explains why:

    It's best to minimize data movement as much as possible. My experience is that maintainability is inversely proportionate to the amount of data that moves between objects. Though you might not see how yet, you can actually eliminate most of this data movement.
    And I agree with him, the more getters and setter you have, the more complexity you add to the system, and since accessors violate the encapsulation principle, you can end up developing a complex and poorly designed system.

  7. #7
    SitePoint Wizard silver trophy kyberfabrikken's Avatar
    Join Date
    Jun 2004
    Location
    Copenhagen, Denmark
    Posts
    6,157
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by phpimpact View Post
    ... the more complexity you add to the system, and since accessors violate the encapsulation principle, you can end up developing a complex and poorly designed system.
    Note that this is true for direct property access as well. What Holub is advocating, is to abstain from exposing the data through any means.

  8. #8
    Resident Code Monkey Chris Corbyn's Avatar
    Join Date
    Nov 2005
    Location
    Melbourne, Australia
    Posts
    713
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Just thought I'd chime in and throw my $0.02 cents into this thread (whaddya mean we don't have 2c coins in Oz?! ).

    When I started writing OO code I never used accessors at all. Everything was done by assigning to properties. When I gained a little experience and saw the benefits of using accessors I used them for everything, but I didn't make them all public.

    Now (in the past 8 months or so) I only use accessors for providing public or protected access to fields. Anything which I assign to in private I'm more than happy to make that assignment directly. I think this is clean and reduces all the setter clutter you often have in OO code.

    When it comes to testing your code having the accessors for the public API makes a massive amount of difference too.

  9. #9
    PHP/Rails Developer Czaries's Avatar
    Join Date
    May 2004
    Location
    Central USA
    Posts
    806
    Mentioned
    0 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by AlienDev View Post
    Hi,

    I couldn't find anything on this, probably because I dont have a clue what to search for!

    Can someone please explain why, in a class's method, I should use a seperate method like setSomething() to set/edit a class's property rather than accessing the property directly. For example, why use:
    PHP Code:
    $this->addErrorMessage($msg); 
    ...instead of just:
    PHP Code:
    $this->errorMessages[] = $msg
    ?

    Mike
    I pretty much agree with what everyone here has said so far, but I'll offer you a different reason to use accessor methods as well: change.

    By using a method, you can easily change the underlying implementation without breaking any code. So for example if you were to one day change the $errorMessages array to be an $error object instead, you would simply change your method to something like:

    PHP Code:
    public function addErrorMessage($msg) {
        
    $this->error->add($msg);

    And you're done. With the direct property access, you would never be able to change the implementation of storing error messages without serious system-wide implications.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •