👿 Setters are the root of all evil (in OOP)

One of the first things you learn, when you're learning about Object-Oriented Programming is to encapsulate your attributes and use “getters” and “setters” to access them.

I want to tell you that this is a awful idea and poor class design.

Setters are bullsh*t

There is no need for setters. There I wrote it. In languages like PHP or JavaScript we have the possibility to make something nullable. Which automatically leads to checks like:


  if ($something→getValue === null) {
      //...
  }

Otherwise you would run into null pointer exceptions.

With newer version with PHP this danger can be reduced by using types for the attributes. But even in languages like Java you would instantiate the object with default values. And often this default values are entirely useless and is indicator that no time was spend into the design of that class.

I’ve often here the comment: “Well, the developer needs to know how to use the class and which methods to call to work properly”. This is not a proper argument. You as developer have a responsibility to defend your code against bullsh*t. May this be strange values or wrong/missing calls.

Marco Pivetta talks about this in his Talk "Extremely Defensive PHP" : https://www.youtube.com/watch?v=8d2AtAGJPno&ab_channel=PHPSouthWestUK

The only injection point is the constructor

Setters are not an additional injection point for a constructor. There should only be one: The constructor. The checks for the attributes should be done in the constructor.

Otherwise, it should fail with an Exception.


class Lastname {
    private string $value;

    public function __construct(string $value)
    {
        if ('' === $value) {
            throw new \InvalidArgumentException('Last Name can not be empty');
        }

        if (!preg_match('/^[a-zA-Z]+$/', $value)) {
            throw new \InvalidArgumentException('Last Name can only contain letters');
        }

        $this->value = $value;
    }
}

In this example we have two specifications for a last name: I can’t be empty and should only contain of letters. Remember this is just an example and does not reflect a real scenario. In this case we secured are object against an invalid usage. This can not be compromised from the outside (only if you change the code itself, but this is why we do code reviews).

But I need to change an attribute

So we need to change an attribute? Okay than it is not a “set” but a “change”.

Based on Domain Driven Design we should name the methods and attributes properly. And in most cases if we have to “set” a thing, we have to “change” that thing.

The most common example is probably the last name change if someone marries.


class Lastname {
    private string $value;

    public function changeName(Lastname $newName)
    {
        $this->value = $newValue->value();
    }
}

Conclusion

Don’t use setters. Defend your code against invalid usages by defining what can be done. Don’t expect someone to be smart. Don’t be smart your self. Defend your code and you’ll automatically code better.