It’s called a Plain Old Data Structure (PODS). They are fairly common in places where data first enters a system from an external source, like a database. In effect their single responsibility is to abstract that external data into a form that’s easier for higher layers to consume.

In other words, it allows programmers of higher layers to work with familiar native objects rather than having to sprinkle accesses to the external source throughout the code. That data is read into the system in one place, and only that one place must change if the interface to the external source changes.

Like any principle, it can be taken too far. If they’re commonly using a PODS on internal-only data, it’s probably misguided in OOP. Note however that passing around a PODS is a fairly common pattern in functional programming, for better or worse.

When you encapsulate data, you’re limiting yourself to only being able to perform a limited number of operations on it. But often there’s an unbounded number of things you want to do with data.

Suppose we’re writing a simple role-playing game. Let’s write a Weapon class and examine what happens if we hide all its data.

public class Weapon {
    private int damage;
    private int accuracy;

    public Weapon(int damage, int accuracy) {
        this.damage = damage;
        this.accuracy = accuracy;
    }
}

Naturally, we want to be able to hit people with the weapon. So we need a function that calculates the damage we’ll do to the enemy. But all the weapon’s variables are private, so we’ll have to turn that function into a method.

public int hitEnemy(Enemy theEnemy) {
    return theEnemy.getDefense() - this.damage;
}

We’ll also need a way to determine if we succeeded in our attack. Again, this’ll become a method.

public boolean tryToHit(Enemy theEnemy) {
    return random() > (theEnemy.getEvasion() - this.accuracy);
}

Later on we find that we want to compare two weapons to see which one has more damage. Another method.

public Order compareDamage(Weapon other) {
    if (this.damage > other.damage) {
        return Order.GREATER;
    } else if (this.damage < other.damage) {
        return Order.LESS;
    } else {
        return Order.EQUAL;
    }
}

A few days later we decide that a weapon’s price should be determined based on its damage and accuracy…

public int getPrice() {
    return 10 * this.damage + 0.5 * this.accuracy;
}

The following week we want to give weapons ratings from C to A based on their stats…

public Rating getRating() {
    if (accuracy/10 + damage > 10) {
        return Rating.A;
    } else if (accuracy/10 + damage > 5) {
        return Rating.B;
    } else {
        return Rating.C;
 }

As you can see, every time we need to do anything new with the weapon, we need to throw that into the weapon’s class to get at its variables. That’s bad – it violates the Open/Closed Principle, which states that code should be open to extension and close to modification. If we had turned Weapon into a plain old data object – a simple record with nothing but public data – we’d be able to add functions to use weapons in new ways without having to modify the Weapon class.

When you design an abstraction X, you must distinguish between things X does and things I can do with X. Our weapons don’t do anything, so there’s no implementation details to hide. Hiding all their data behind private variables is about as useful as a list that doesn’t let you access its elements. Our game will definitely need some encapsulation and abstraction, but it should be implemented at a higher layer, in the game logic proper.