Re: [OT] "Fluent Interface"? Welcome to NeXT
Re: [OT] "Fluent Interface"? Welcome to NeXT
- Subject: Re: [OT] "Fluent Interface"? Welcome to NeXT
- From: "Clark Cox" <email@hidden>
- Date: Thu, 2 Aug 2007 20:00:56 -0700
On 8/2/07, Jeff Laing <email@hidden> wrote:
> > Just saw this on Fowler's blog, and it reminded me of old-style
> > Objective C returning self all the time, and how I was very sad to
> > see it go in a lot of ways.
> >
> > http://www.martinfowler.com/bliki/FluentInterface.html
> >
> > Who knows, maybe ObjC4 will be called "fluent"... :-)
>
> One can only hope not. The thing about these pissy examples is that by
> leaving out all error handling, they trivialise the problem then claim an
> elegant solution. If you look at his original method:
>
> private void makeNormal(Customer customer) {
> Order o1 = new Order();
> customer.addOrder(o1);
> OrderLine line1 = new OrderLine(6, Product.find("TAL"));
> o1.addLine(line1);
> OrderLine line2 = new OrderLine(5, Product.find("HPK"));
> o1.addLine(line2);
> OrderLine line3 = new OrderLine(3, Product.find("LGV"));
> o1.addLine(line3);
> line2.setSkippable(true);
> o1.setRush(true);
> }
>
> (I mean to start with its unbelievable that anyone would code up literal
> amounts like this - putting that aside)
>
> Similiarly, if you look at the fluent version:
>
> private void makeFluent(Customer customer) {
> customer.newOrder()
> .with(6, "TAL")
> .with(5, "HPK").skippable()
> .with(3, "LGV")
> .priorityRush();
> }
>
> how did that skippable() method know what it was applied to - the assumption
> is that the return from the with() was still an order, not an order line.
This was a very common idiom in earlier Obj-C. Well before "void"
existed, every C function (and therefore Obj-C method) had to return a
value. It was common to return self on success, and nil on failure.
That way, method calls could be chained as above.
Since sending a message (that returns an object) to nil is essentially
a no-op, the first method to return nil (indicating failure) will
break the chain.
> On the other hand, perhaps skippable() is a method of the order that
> modifies the last item in the order and returns the order. Or its a method
> of the customer that modifies the last item in the current order. Thats
> about as counter-intuitive as I can imagine, unless you commit to doing your
> coding in this cascaded style.
>
> Going back to the original, what happens if *any* of those Product.find()
> calls fails? The order goes ahead anyway. In fact, this order got added to
> the customer regardless of whether it managed to get formed at all.
>
> You could have coded the above as something like
>
> [customer addOrder:
> [order orderWithLines:
> [orderline lineForProduct:@"TAL"
> quantity:6],
> [orderline lineForProduct:@"HPK" quantity:5
> skippable:YES],
> [orderline lineForProduct:@"LGV"
> quantity:3],
> nil
> rush:YES]
> ];
>
> and I actually see that as being that much better in terms of readability,
> but is it really good form to use this sort of thing in Cocoa; surely one is
> actually going to check errors?
>
> Isn't this just pushing towards a C++ try/catch model which appears to have
> been bolted on to Objective-C as an afterthought?
--
Clark S. Cox III
email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden