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:

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.

2. Dev knows, from all of the OOP dogma that's been beaten into his skull, that creating public class members violates encapsulation. (Egads!!!)

3. Dev sets each of the dozen class properties to private.

4. 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.

5. 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.

6. 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:

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"???