Get, set... STOP!
Tags: php, programming, beginners, codequality
Published: 2020-05-12 14:56:36

---
title: Get, set... STOP!
published: true
description: One behavior, deeply embedded into the hearts and minds of many software developers is the creation of getters and setter on entities. It is so widespread that IDEs have tools to do it automatically. Why do we do it? Does it serve some purpose or is it just a cargo cult programming ritual?
tags: #php, #programming, #Beginners, #codequality
cannonical_url: https://madewithlove.com/getter-setter-never/
cover_image: https://dev-to-uploads.s3.amazonaws.com/i/4uefggshxyp783qarsdy.png
---


*What if I told you [Morpheus](https://matrix.fandom.com/wiki/Morpheus) never said: “What if I told you?” I know you saw that meme a thousand times but have you actually heard him say it in the movie? You didn’t, because it didn’t happen. Darth Vader also never said “Luke, I am your father” and Captain Kirk never said, “Beam me up, Scotty”. People keep repeating these “quotes” so we assume they are true.*

## Cargo Cult

This phenomenon is not limited to spoken word — it afflicts human behaviors also. Since software is developed by humans (for now), we come across it in software development. It’s called cargo cult programming and [Wikipedia](https://en.wikipedia.org/wiki/Cargo_cult_programming) defines it as:
> “Ritual inclusion of code or program structures that serve no real purpose.”

One practice that is widespread among developers is the creation of getters and setters. They always come together and we create them as soon as the entity is created. This is so deeply engrained in our workflow that nowadays IDEs offer to automatically generate these getters and setters for us.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/a8dl2v9j7s387bkdm6z9.png)

But is there a reason for doing this or is it just a ritual we have accepted without stopping to wonder why?

## Set the lights to off

Let’s look at the *setters* first. By setters I mean methods like this:
```php
public function setName(string $name)
{
  $this->name = $name ;
}
```

This method clearly changes the name of the object in question. In the real world, we call this renaming. I have never heard someone say that a person has *“set its name to another name”*. Even if you ask the developer who wrote the method chances are they will tell you that it renames the object. So, here’s an interesting proposition for you: if renaming is what the method does, call it *rename*.

```php
public function rename(string $name)
{
  $this->name = $name ;
}
```

Now our method name describes precisely what our method does and we used a domain-specific word for it. The (domain) concept of renaming a user is reflected in our code. This gives developers and non-developers a common ([ubiquitous](https://martinfowler.com/bliki/UbiquitousLanguage.html)) language when discussing the project.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/hkya50e8w785mf8hqmwo.png)

Let’s look at another example. Say we have a `Subscription` class with the following setter method:
```php
public function setActive(bool $active): void
{
   $this->active = $active;
}
```

As with the previous example, this method doesn’t clearly reflect the domain concept which is activating and deactivating a subscription. So we split it into:

```php
public function activate(): void
{
     $this->active = true;
}

public function deactivate(): void
{
    $this->active = false;
}
```

Again we have expressed these concepts explicitly in our code; furthermore, there is another benefit gained by this refactoring. Having a setter method allowed the outside world to set the internal state of the `Subscription` object, whereas now, the `Subscription` object is responsible for setting its own internal state. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/c8cwld3zrpa6lp7xkv4o.png)

## Anemic vs. Rich
By having myriad setter methods on your entity, you end up with what’s called the anemic domain model.

```php
<?php 
class User {
    public function setName(string $name): void
    //...
    public function setBirthDate(DateTime $date): void
    //...
    public function setAddress(Address $name): void
    //...
}
```

Your `User` entity is more of a data structure than an object. Data structures expose their data and have little or no behavior while objects protect their data and expose behaviors.

To have a richer domain model, we refactor this to:
```php
class User {
    public function __construct(string $name, DateTime $birthDate, Address $address)
      {
        $this->name = $name;
        $this->date = $birthDate;
        $this->address = $address;
      }

    public function rename(string $name): void
    //...
    public function updateAddress(Address $address): void
    //...
}
```
Now our User class is protecting its internal state (invariants) and exposing only behaviors to the outside world.

## “Get me your name”
Now, to the getters. From my experience, this is harder for people to get (pun intended), and, to be clear, by getters I mean methods like this:

```php
public function getName() : Name 
{
   return $this->name;
}
```

This method returns the *name* of the object in question. Many developers would say this is clear from its name. The get + Name tells us it returns the Name. Actually, the “get” prefix guarantees nothing. In actuality, it is the return type of the method that guarantees this method returns a Name.


If you ditch the *get* prefix in the method name then you lose no information in the process:
```php
public function name() : Name 
{
   return $this->name;
}
```

If you can remove a word without losing any information, then that word is just noise.

But this is how we talk, right? Not really. Recall from memory a situation where you need to reveal some personal information about yourself such as being in a bank. When the bank clerks ask you for your address, do they say “Get me your address” or “Get me your name”? They don’t. 

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/g1kmkb11l5lxb11wlnaw.png)

In fact, when we use the word get in real life it usually isn’t a question but an imperative that has some implied side effect. Say you want a beer so you tell your friend “Hey, get me a beer from the fridge”. The side effect of him getting you a beer is that the freezer will have one less beer afterward. This will happen every time you call him to get you a beer. I’ll admit, it would be nice if beer fridges would follow our programming conventions of “getters” not changing the internal state of the object, but they don’t.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/ra33n2tfjoawf6pzbzgy.png)

---
Naming things in software development is hard and we want to be as precise as possible when doing it. What if I told you get and set are among the most [Ambiguous](https://www.youtube.com/watch?v=ZsHMHukIlJY&t=39m22s) words in the English language. Check google and see how long the list of their possible meanings is.

Maybe they aren’t the best candidates when you’re aiming for precision.