Builder Pattern and Persistence

Question

I use the Builder pattern for several classes of my project (multiple arguments, some mandatory, some optional, etc.). These classes are immutable (no setters, deep copy for collections getters).

I am now trying to store those objects in a database using a persistence framework that constructs objects with default constructor + setters. It doesn't like my Builders very much!

I don't want to degrade that setup to POJOs and lose the advantages of the current design (flexibility, immutability, construction security).

I would welcome any feedback on workarounds that can be used in this situation (I could wrap each of these classes but that would double the number of classes and I would rather avoid that).

One post actually points that as a specific disadvantage of the Builder pattern.

EDIT

One answer proposes to use private constructor / setters but that only works if the fields of the class are not final, which is not my case.

FINAL EDIT

Thanks to all.
What I think will be my final solution looks like this and works fine (for the record, I'm using MongoDB + Morphia):

class AClass {
    private final String aField;
    private final AClass() {
        aField = "";
    }
    //Standard builder pattern after that - no setters (private or public)
}

Can't you include setters and default constructor but make them private? — DaveJohnston, Feb 22 '12 at 15:24
I know Hibernate can use private setters and constructor, just wondering if you have anything against this for your specific case. — DaveJohnston, Feb 22 '12 at 15:27
As explained below, the fields in my class are final so I can't use private setters. Otherwise your solution would work. Question edited. — assylias, Feb 22 '12 at 16:36

score 6 · Accepted Answer · answered Feb 22 '12 at 15:50

6

As I said in my comment: you can include a default constructor and all required setters but make them private. This way you maintain the immutability of your Objects but an ORM such as Hibernate will be able to access the methods/constructor when it needs to.

Anybody else would be able to access these methods using reflection too, but then they can access the private member variables using reflection too. So there is no real downside to adding the private methods.

answered Feb 22 '12 at 15:50

DaveJohnston

10,031
10
54
83

2

That works if the fields aren't final. But if they are then I can't use default constructor / private setters for obvious reasons. – assylias Feb 22 '12 at 16:35
3

If the persistence framework is using reflection to access a private constructor, then it should be able to set the classes fields directly. This works even if the fields are final. – TDJoe Feb 22 '12 at 16:48
1

Setting the fields to final is obviously part of making an Object immutable, but if there is no public method for mutating the Object, is there any need for the fields to be final? Other than to ensure you don't modify the values accidentally yourself in methods internal to the class? – DaveJohnston Feb 22 '12 at 17:05
1

After some trial & error, it works by creating a default constructor that assigns dummy values to the final fields, without providing private setters (so I can leave my fields final) as the framework seems to do what @FFJoe says above. – assylias Feb 22 '12 at 17:16

Builder Pattern and Persistence

1 Answers1