Design Pattern to deal with a class with many members (not Builder)

Question

I have a class with many members (~20). I would like to initialize it nicely so a constructor is not an option (due to the many parameters) because of the bad code readability.

So I tried to use a Builder DP. The only problem with it is that it's very nasty when it comes to extending such a class.

Any suggestion on what Design patter should I use to deal nicely with this situation (class with many members)?

Thanks a lot!

Will you have default values for most of the attributes, so you can apply the *Prototype* design pattern and create new objects by simply cloning a prototype? — user1438038, Nov 19 '14 at 14:34
Maybe it will be better to split this class into several classes? — pomkine, Nov 19 '14 at 14:36
@user1438038 - good suggestion but unfortunately there are no default values for most of the attributes (it's a class holding many data) — Vitali Melamud, Nov 19 '14 at 14:44
@JordiCastilla - I can use a map but the members are of different nature and i'm not sure that access by "string" field name is a good solution to me — Vitali Melamud, Nov 19 '14 at 14:45
dont need to use a string, can be an id, another object or simply a count position... `Map`.... — Jordi Castilla, Nov 19 '14 at 14:50
using an `enum` as key would be another option (preferably with an `EnumMap`) — Max Fichtelmann, Nov 19 '14 at 15:07

score 1 · Answer 1 · answered Nov 19 '14 at 14:49

20 fields with no defaults is an awful lot. There must be some way to either split the class into multiple classes or group some of the fields into Compound objects.

For example if you have fields for street, country, district etc you could group those all into a single Address object.

If you can do that a couple of times then your constructor should become manageable.

Also if you have 20 fields without any defaults, then you have to specify all the fields anyway so the Builder pattern loses its value. You might as well use a constructor.

score 1 · Accepted Answer · edited May 23 '17 at 10:33

As you say, 20 fields is a lot for a constructor. Regarding readability, the pattern that comes to my mind is static factory methods (but in the sense of Joshua Bloch's Effective Java, not the Factory Method of GoF book).

As he says in the book (in its Item 1), static factory methods have names (unlike constructors) so that a static method with a well-chosen name is easier to use and the resulting client code easier to read.

class ManyFields {
    T a;
    U b;
    (...)
    V t;
}

That way, you could do things like

ManyFields.withAtoFzeroed(g, h, i, ..., t)
ManyFields.onlyGandJ(g, j)
ManyFields.consonantsZeroed(a, e, i, o, u)
(...)

That is, adapt/coin new static factory methods addressing different usage patterns in your code is easier to do and more readable.

Of course, having a set of default values would help on that, since the number of parameters needed in those methods would be reduced.

Besides, static factory methods do not have to create a new object each time they’re invoked, allowint predefined instances, caching, etc. As a result, if equivalent objects are requested often, you can improve performance with this technique, apart from highlighting the most typical objects used for your class.

Nevertheless, the efectiveness (in terms of readability) of a bunch of static factory methods usually depends on how well you can group those parameters in terms of common values, default values, etc. which usually arises the need of splitting such a big class into smaller classes and using composition (as @dkaztel suggests).

Anyway, when dealing with many constructor parameters, the best approach is usually a Builder.

Given you want to avoid it, you can improve also the readability using method chaining for your setters.

ManyFields obj = new ManyFields();
obj.a(A).b(B).d(D).t(T).v(V).f(F);

This answer about builders and fluent interfaces can also be useful.

score 0 · Answer 3 · answered Nov 19 '14 at 14:55

Maybe this is really silly, but you could make a new Entity class with a whole bunch of Setters. That'll let you build the object any way you like, either with a builder, loader, or whatever.

Then, make your current class accept a single parameter of that Entity type and in the constructor call some sort of Validate method on it to make sure it's complete, and then use the data stored in the Entity to power the class.

It might be a lot of boilerplate code to create the entity and its validation rules, but actual usage of the class will become very straight forward.

Design Pattern to deal with a class with many members (not Builder)

3 Answers3