2

I see (and write) a lot of code like this:

class MyClass
{
    private $_myProperty;

    public function setMyPropert($myProperty)
    {
         $this->_myProperty = $myProperty;
    }

    public function getMyProperty()
    {
         return $this->_myProperty;
    }
}

Since we are taught that class properties should always be private.

However, i really just want to do this in the above scenario:

class MyClass
{
    public $myProperty;
}

Thats much less code and easier to read. But other developers would look down on this code and most likely it would fail code reviews etc. Even if not, i would still never do this for fear of someone else seeing it and making judgement.

Why though? Is this something that is just ingrained in developers of oop code? Or is there another reason that I'm missing, perhaps related to testing, future maintenance or other non obvious technical reason. I am talking specifically in a scenario where the getter/setter does noting more that get/set.

Marty Wallace
  • 34,046
  • 53
  • 137
  • 200
  • 3
    http://stackoverflow.com/questions/1568091/why-use-getters-and-setters – Klaasvaak Aug 28 '13 at 19:58
  • Good question again. Simple but complex to answer, especially with a focus on PHP. Please keep on asking. For this one here I don't have the time to answer, but I have the strong feeling this depends on the type of object (Value, Helper, Operator, Object/Immutable or not). Having getters and setters often protects you from making a wrong decision thought, so keeping things private that belong to an object (e.g. a "property") is not that much off the track and makes your code somehow future proof in PHP. – hakre Aug 28 '13 at 22:48

2 Answers2

1

If you are doing nothing in your getters and setters, then yes, you may as well just make the property public. But setters are typically used to check the value to make sure it's valid:

public function setFoo($foo) {
    if (!is_string($foo)) {
        throw new InvalidArgumentException('No you foo-l!');
    }
    $this->foo = $foo;
}

It's a good idea to do that to ensure the integrity of the class, that's what encapsulation is for. And even if you're not doing this checking now, you may be adding it in the future after you have fixed the 3rd bug resulting from something setting invalid values. If you then suddenly start switching to method calls instead of property assignment, you'll have a hard time retrofitting all your code that's setting properties.

Best start with actual encapsulation as early as possible.

deceze
  • 510,633
  • 85
  • 743
  • 889
0

This really comes down to the open/closed principle:

software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification

In this context, the principle means that the members of a class should be private by default.

It might seem like, in some cases, you can just declare a public member. You can, but it's still true that you shouldn't do it as a rule. It's partly just avoiding bad habits -- exposing all a class's members to everyone is just sloppy.

It's also a question of signalling your intent: if someone sees a public member, what do they think? There's no immediate way of knowing if the author intended for the member to be public, or if they just didn't really know what they were doing.

McGarnagle
  • 101,349
  • 31
  • 229
  • 260