Private class data design pattern in Java

Question

I'm reading about private class data design pattern here and I'm trying to understand what it can really accomplish.

From what I understood private class data design pattern is a structural pattern aiming to reproduce "readonly" attributes even for the class itself: while "private" attributes are visible and editable only to the class itself, attributes in the "private class data" can't be changed at all (even by accident). The only solution is to provide a setter in the private class data, although (at least in my opinion) if the private class data has all the setters of the attributes, then we might have defeated the pattern very purpose.

Assuming my understanding is correct, this lead to a question: Even if the main class can't change any private class data attributes, it can set the reference of the private class data itself, populating it with the variables it wants to change.

In other words, an uncaring developer might do something like this:

public class MainData {
    int foo;
    int bar;
    public MainData(int foo, int bar) {
        this.foo = foo;
        this.bar = bar;
    } 
    public int getFoo() {return foo;}
    public int getBar() {return bar;}
}
public class Main {
    private MainData mainData;
    public Main(int foo, int bar) {
        this.mainData = new MainData(foo, bar);
    }
    public doSomeWork() {
        //correct behaviour
        this.mainData.getFoo() + this.mainData.getBar();
        //now I want to trick the pattern
        this.mainData = new MainData(this.mainData.getFoo(), this.mainData.getBar()+4);
        //I've changed bar :(
    }
}

Since the "readonly" attribute is not compile-enforced (unlike C# via readonly reserved word), in Java a lazy developer might do something like this. If it's true, then why should we use this design pattern at all? Unlike other patterns (like singleton) this pattern doesn't enforce anything, so why should we using it at all?

• It would be great if you can provide example where you've used this pattern and it concretely helped you solving some software issue;
• Let's stay on Java: I know in C# everything is much easier, but there the pattern is just plain silly because of readonly reserved word;

Thanks for any kind reply!

Answer 1

The author that wrote the Private Class Data says that the intent of that so called pattern is:

Intent

• Control write access to class attributes
• Separate data from methods that use it
• Encapsulate class data initialization
• Providing new type of final - final after constructor

Let's take a look at the intents one by one

Control write access to class attributes

My Opinion is that controling write access to class attributes is simply done by methods and modifiers. OOP calls this Encapsulation

Separate data from methods that use it

That doesn't make much sense to me, because object oriented programming means to bring data and methods together. That what an object is about. Separating data from methods that use it seems to be an anemic approach.

Encapsulate class data initialization

That is what I do in a constructor. I don't see the benefit of moving this code to another class.

Providing new type of final - final after constructor

This intent aims to make the reference to the data class final, but don't make the attributes in the data class final. I guess that is why it is called a "new type of final". Since the data class only holds data and the methods are separated from them, the data can not be modified if there is no setter on the data class. In this case the data is immutable. Thus I don't see the benefit of a data class to just making the class's field final.

My conclusion

I think that this so called pattern adds complexity without much benefit. Therefore I would not use it. And I call it a "so called pattern", because

In software engineering, a software design pattern is a general reusable solution to a commonly occurring problem

I don't see the commonly occuring problem.