Should XExtensionItemMutableParameters be replaced with a builder class?

[irace]

Mutability should be avoided. A great way to provide an easy-to-use object creation API is by using the builder pattern.

Unfortunately, many Objective-C developers seem adverse to using builders. As such, the first version of this library includes the XExtensionItemMutableParameters subclass, which allows one to create an XExtensionItemParameters instance without using its initializer (which takes a large number of arguments).

I'd prefer a builder but want this library to be as approachable as possible. The introduction of a builder class means XExtensionItemMutableParameters would be deleted altogether, and XExtensionItemParameters's large initializer would be made private. The only way to get an instance would be to use the builder object and then call build at the end.

[robb]

I'd prefer a builder over that monster of an initializer any day

[irace]

I'd prefer a builder over that monster of an initializer any day

❤️ @robb

[mbbischoff]

I'd prefer a builder over that monster of an initializer any day

Me too, but I prefer mutable subclasses ever so slightly to builders.

[khanlou]

Objective-C initializers are basically factory methods anyway (since they can return any object or even nil), so an initWithBuilder: isn't that scary of an idea, imo.

[irace]

Me too, but I prefer mutable subclasses ever so slightly to builders.

@mattbischoff Mutable subclasses and monstrous initializers go hand in hand. You need the latter in order for the former to be of any use.

[lazerwalker]

I'm personally a +1 for using builders.

I wonder if it might be an acceptable compromise to offer a builder, but not deprecate the mega-initializer. People who are that scared of using a builder can just use the nasty verbose initializer.

[irace]

Mutable subclasses and monstrous initializers go hand in hand. You need the latter in order for the former to be of any use.

I guess this is not technically true. The mutable subclass could be defined in the same file as the immutable base class, and the monstrous initializer would be made internal to the .m file. This is what I would do if I added a builder class anyway.

[robb]

Are there any default parameters?

[irace]

Are there any default parameters?

No

[robb]

Unrelated to this one, but I've used a builder for requests before and enjoyed being able to have format strings along the way, e.g.:

[[[[XYRequestBuilder
    GET:@"/users/%@/", userID]
    params:@{ @"foo": @"bar" }]
    whatever:&amen]
    build];

[irace]

I feel like a big part of why some iOS developers don't seem to be fans of builders is that they assume that most of the value comes from the method call chaining commonly associated with the pattern, which generally looks aesthetically terrible in Objective-C.

I've made plenty of Objective-C builder classes that don't expose a fluent interface yet still provide all of the other benefits of separating out object construction.

[irace]

I think keeping the mutable subclass around but providing a convenience initializer that takes a block with an XExtensionItemMutableParameters instance as the argument is a good balance. It keeps the mutable class around for those who are allergic to builders, yet adds a convenient way to initialize that doesn’t require calling the (currently very long) designated initializer.

- (instancetype)initWithBlock:(void (^)(XExtensionItemMutableParameters *mutableParameters))configurationBlock;

[mbbischoff]

Agreed. Great solution.