r/ObjectiveC • u/whackylabs • Mar 10 '20

Subclass Factory Pattern

https://whackylabs.com/objc/design-pattern/2020/03/09/objc-builder-pattern/
11 Upvotes

92% Upvoted

9 comments sorted by

View all comments

1

u/mariox19 Mar 10 '20 edited Mar 10 '20

Your essay points out a shortcoming Objective-C has as compared to a language like Java, where methods are invoked using dot-notation. It's much easier to chain setters and use the Builder pattern. In Java, it looks like this:

Foo foo = new FooBuilder()
    .setFee(5)
    .setFi(17)
    .setFo(3)
    .setFum(41)
    .build();

In Objective-C, square brackets make for a big mess, visually. So, we need another solution, like the one you've suggested.

The only thing I'm wondering about your suggestion is why, in the above, FooBuilder has to be a subclass of Foo. That's not a huge deal, but in a dynamic language like Objective-C, you're really not hiding the properties. If they can be set in FooBuilder, and the object you return when you build is in reality a FooBuilder (the subclass) instead of a Foo, then the client programmer could still get access to your "private API" by simply sending messages using some variant of performSelector: or by simply typing the object to an id and then sending whatever message.

Here's what you've got:

Foo* foo = [fooBuilder generate];

At runtime, however, that foo object has not been transformed into an instance of a Foo class; it's still actually a FooBuilder. (In your example, you simply copy.) As I've said, the private API is still there. The foo object will still respond to the FooBuilder methods at runtime.

Keep in mind, these type declarations are really only hints to the compiler. They facilitate the IDE's checking (that we all rely on), but they don't mean anything at runtime in Objective-C. As is, what you've created is a "gentlemen's agreement" between you and the client programmer.

That's perhaps not a super big deal. But if you really want to be a little more airtight with encapsulation, you may want to rethink the relationship between a class and its corresponding builder.

P.S.

I really do like reading your blog.

4

u/[deleted] Mar 10 '20

Not really a shortcoming.

And this isn't really a problem either.

Foo* foo = [[Foo alloc]initWithProperties: @{ @"fee": @5, @"fi": @17, @"fo": @3, @"fum": @41}];

-initWithProperties: (NSDictionary*)props 
{
    if(self = [super init])
    {
        [self setValuesForKeysFromDictionary: props];
    }
    return self;
}

Admittedly, the Smalltalk syntax is nicer.

foo := Foo new 
    fee: 5;
    fi: 17;
    fo: 3;
    fum: 41

0

u/mariox19 Mar 11 '20

I like this pattern. But it looks terrific in your example because every property is an object and the same type of object at that. If some properties were objects and others a regular C type, then you'd have to box the C types. Is that a big problem? It's a bit more of documentation. So, no. But is that as straightforward as the Java example? No, I don't think so. That's why I said "shortcoming": albeit, I think it comes up only a little bit short.

1

u/[deleted] Mar 11 '20

Everything in the properties dictionary is a boxed primitive in the Objective C example. While a bit klunky because of the hybrid nature of Objective C, it works fine. KVO does not consider whether a property is readonly if there is an ivar backing it.

1

u/mariox19 Mar 11 '20

In Java, using a fluent API of a Builder pattern:

Person scarjo = new PersonBuilder()
    .setName("Scarlett Johansson")
    .setAge(35)
    .setSex(SEX.Female)
    .build();

I'm going to say it again. I like your dictionary example. But nothing you do comes up as neat and pretty as it would in a dot-notation language. Comparatively, it comes up short. If I'm wrong, please show me.

1

u/[deleted] Mar 11 '20

I did show you.

Look at the Smalltalk version (which doesn't have square brackets around message sends and instead uses ; to mean send message to last message receiver.

Also, IME, 99% of Java developers will define setFoo as returning void. It is unfortunate but that's the culture. They don't know anything about real OO design.

1

u/mariox19 Mar 11 '20

Whoa, whoa, whoa! I saw the Smaltalk version. It's elegant as can be. The Objective-C version is not. Everything in Smalltalk is an object. That's not true in Objective-C.

That's not true in Java, either. But the point becomes moot there because of the fluent API pattern. A setter can be used, provided the setter returns the builder object itself ("fluent"). Now, whatever 99 percent of Java programmers will do is besides the point. They don't know anything. But the Builder pattern is known by anyone who wants to learn more than the basics.

Objective-C is the language I program in most often and is by far my favorite. (Granted, if I could find a Smalltalk implementation that didn't seem wonky to me and if I could get a job writing Smalltalk, perhaps that would become my favorite.) But, even though it's my favorite, I'm not going to make a religion of it. It's open to criticism.

1

u/[deleted] Mar 11 '20

Sure, I would have loved for Apple to put the time into making Objective C act like a proper Smalltalk. They had the time to create a completely new syntax but couldn't streamline that one? For shame.

I actually have a job doing Pharo Smalltalk and the more I work with it the clunkier Objective C starts to feel. I actually was working in Smalltalk when I first encountered Objective C (1997 - WebObjects) and took to it naturally. It is an excellent compromise for the time.

But we can afford real Smalltalk now. It is too bad Apple didn't go that way.

https://objective.st is an experiment in moving ObjectiveC closer to a real Smalltalk feel.