DEV Community

Masturbatory Code in OOP

Adam Nathaniel Davis on February 24, 2020

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

Read full post

peerreynders • Sep 17 '20

"Those Who Do Not Learn History Are Doomed To Repeat It"

Alan Holub: Why getter and setter methods are evil (javaworld.com, 2003)

Tell, Don't Ask (2013) - pdf (2003)

Constructor Initialization (2006) vs Setter Initialization.

There is also the notion of an opaque data type. Even if the internal structure is publicly accessible the convention is to only interact with a type instance via publicly available functions.

That way the type's "clients" stay decoupled from the internal structure of the type (anything may be restructured, added, or removed in the future) and whether or not the result is computed or stored (cached).

// file: person.mjs
export function makePerson(age) {
  return {
    first: age
  };
}

export function age({first}) {
  return first;
}

import {makePerson, age} from './person.mjs';

const p = makePerson(25);
console.log('Age:', age(p));

Adam Nathaniel Davis • Sep 18 '20 • Edited

I certainly appreciate the feedback. But I'm not sure exactly what you're inferring in your response. so my reply might, admittedly, miss the mark. But here goes:

Even if the internal structure is publicly accessible the convention is to only interact with a type instance via publicly available functions.

I think my entire objective on this is to rail against "convention". Convention has its place. And I'm not claiming we shouldn't care at all about convention. But the whole point of this article is to point out the silliness of convention-for-the-sake-of-convention.

I'm not against the idea of having getters and setters. And I understand the theory of why getters/setters are encouraged. But if you're creating getters/setters just to tick off some checklist in your computer science class, you're missing the whole point.

I fully understand that, sometimes, you create a whole batch of getters/setters because you're essentially wireframing new code. And you know that, at some point in the near future, there will be additional logic inside those getters/setters. So you create them as a kind of scaffolding and, fairly soon, you end up adding the logic to them.

But if you're "scaffolding", for some kind of assumed future expansion of the code, but you don't know that you'll be building out that portion of the code, then you're just creating unnecessary complexity for the purpose of satisfying some theoretical programming professor.

One way to identify a "code smell" is to find those places where the coder has written a whole bunch of boilerplate code to account for some unforeseen eventuality that may not ever occur. When someone insists on never creating a public variable and always couching every class member in getters/setters (even if those getters/setters don't do anything), then they are committing this same sin.

I think you've read several of my articles, so you might've started to understand this theme from me now: I don't much care whether you love getters/setters - or whether you hate them. What I care about is dogma. I care about the OOP acolytes who get all up in their ivory tower to preach the gospel of getters/setters - even when those getters/setters are a complete waste of time.

peerreynders • Sep 18 '20

And I understand the theory of why getters/setters are encouraged.

From my perspective that practice has been a code smell for at least the past 17 years - unless you're dealing with a DTO.

What is encouraged is to hide access to instance variables behind methods so that implementation details like validation, computation and storage can be hidden away and remain subject to change without impacting the object's public API.

Mindless getters and setters on the other hand hint at lack of design, revealing too much about the object's internal structure which causes its collaborators to be too tightly coupled to it.

Don't ask for the information you need to do the work; ask the object that has the information to do the work for you.

Adam Nathaniel Davis • Sep 18 '20

That was exactly the point of this whole article.

Bruce Wells • Oct 6 '23

The proper OO way to do age is the store birth date. Then have an age() function that does the math. You can't set an age, it can only be reported as it is not something you control.

Here is my take on this topic:

blog.phpfui.com/getters-and-setter...

Eckehard • Aug 28 '21

Hy Adam,

It´s true, you can write Masturbatory Code in any language, but why should you do that? A=A ist also useless. I assume, it´s not THAT funny.

Getters and setters are just a language feature you can use or not. In OOP it´s generally not the best style to expose a class variable to the public, so a getter and setter can give you more control. You could add a value check or initiate any action before or after the value was changed. So, your class can handle a state change while the user of the class justs sets a variable.

I assume you will find useless code very often. Maybe someone just added a setter and getter out of routine and did not think about. Or he wanted to add more code later, or... . So, this is not a bug, but useless code. But does this mean, setters and getters are useless? I suppose, that´s not what you ment.

Isaac Hagoel • Feb 25 '20

P.S
You are waiting for someone to say Redux, aren't you?

Adam Nathaniel Davis • Feb 25 '20

Bwahahahaha! Love his rant.

And, P.S.
As you've noticed from my previous posts, I'm no fan of Redux. But I wouldn't actually call it "masturbatory". It does something. It just does it in a big, convoluted way that could be done so much better with other tools.