Masturbatory Code in OOP
Tags: oop, codequality, getter, setter
Published: 2020-02-24 22:14:20

From Merriam-Webster:

> **Masturbatory**: : excessively self-absorbed or self-indulgent

I've done a lot of OOP work in Java and C#.  Some of it I enjoyed.  Some of it... not so much.  I'm not so much interested in the Coding Holy Wars of OOP-vs-functional-vs-whatever.  But now that I seem to have escaped the OOP world (for awhile, at least), I can't help but rant about a particular practice that still prevails in OOP that drives me nuts:  Absolutely pointless getters and setters.

This is an example that you will find lurking in almost any of the dark corners of an OOP codebase:

```java
public class Person {
    private int age;

    public int getAge() {
        return this.age;
    }

    public void setAge(int newAge) {
        this.age = newAge;
    }
}
```

If you have any computer science background - even if you're "only" a JavaScript or PHP or Python developer - you probably know what's going on here.  We have a basic class `Person` which has a private variable `age`.  `age` is private because the coder presumably wants to adhere to the OOP principle of encapsulation.  

In other words, we don't want other parts of the application to instantiate `Person` and then update the `age` property outside the control of the `Person` object.  If `age` is going to be updated, then we want it to happen precisely the way that it's prescribed in the `Person` class.

This is all fine-and-good. I'm not bothered by the concept of public/private variables.  It can be extremely powerful and, generally speaking, it's a very _good_ thing.  The problem arises when the OOP Acolytes mindlessly adhere to this concept of encapsulation, even when it makes no got-dang sense.

Obviously, the code above is just a simplistic demo.  But I've seen code _just like this_ time and time again in real-life applications.  The process is very simple:

1. Dev creates a new class that he presumes will need a dozen different class properties. 

1. Dev knows, from all of the OOP dogma that's been beaten into his skull, that creating public class members _violates encapsulation_. (_Egads!!!_)

1. Dev sets each of the dozen class properties to _private_.

1. Dev proceeds to set a dozen getters for each of the dozen class properties, that do nothing but blindly return the value to the caller.

1. Dev then proceeds to set a dozen setters for each of the dozen class properties, that do nothing but blindly set the value of the property to whatever value was passed in.

1. Dev then pushes away from the keyboard and ogles his gorgeous, OOP-compliant code that satisfies all the dogmatic dictates that he learned in college.

But all of this boilerplate is syntactic _garbage_.  It serves absolutely no purpose (other than to make someone feel smug-and-secure about their faithful adherence to OOP principles).  

What the OOP Acolytes don't want to acknowledge (or admit), is that in the code sample above, `age` is... wait for it... _a public variable_.

Oh, sure... it doesn't _say_ it's a public variable.  It has that warm, comforting `private` keyword in front of it.  But it's extremely _public_.  It's functionally equivalent to this:

```java
public class Person {
    public int age;
}
```

If you set a variable to _private_, and then you give it a getter that does nothing to alter the value before it's retrieved, and then you give it a setter that does nothing to alter the value before it's set, then there's nothing really "private" about it.  You've handed complete control of that variable over to the caller.  In other words, you've just created a very-public variable - with _a lot more boilerplate code attached to it_.  Umm... _yay_???

## Masturbatory Code

I call this "masturbatory code" because it's code that effectively serves _no purpose_.  Well... that's not entirely true.  The "purpose" it serves is solely to make the coder _feel good_.  Every time they write a superfluous set of getters/setters, it's like they're envisioning their comp sci instructor, or their hardcore OOP friends, smiling over their shoulder and nodding.  They're silently checking that box that says, "_See!!_  I'm a _real_ OOP coder.  And I knows shit!"

I realize that the userbase on this site seems to be largely rooted in frontend dev.  Most of them spend their days writing in JavaScript, TypeScript, PHP, Python, or some other procedural language. So maybe this post seems a bit indulgent on my part.

But "masturbatory code" isn't limited to the grimy underside of OOP.  There are masturbatory practices to be found in _every_ language, in _every_ coding paradigm, and in _every_ development community.  Furthermore, if we're being honest with ourselves, we've _all_ engaged in these masturbatory practices at one time or another.  

I'm not even trying to say that these silly little practices are always empirically "wrong".  Maybe you have a firm reason (in your mind) why these practices are good-and-necessary.  But there's value in understanding them for what they are.  Because if you don't appreciate the true masturbatory nature of these practices, you're more likely to become "that guy".

You know "that guy".  The one who's not content to simply indulge in his own masturbatory techniques - but feels compelled to shout you down or code-shame you because you haven't embraced the same techniques.  The one who's more interested in ensuring that _you_ are coding according to _his_ religious convictions.

> Don't be "that guy".

## Cross-Platform Masturbatory Code

I can think of several examples of "masturbatory code" that I've seen in JavaScript or PHP.  But I'd rather hear _from you_.  What have you seen in your codebase/language/environment that qualifies as "masturbatory"???