Method Chaining

[Caldus]

Hi,

I notice some developers using this kind of syntax:

$object->method1()->method2()->...->methodN(); 

One example is CodeIgniter's database class:

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20); 

I don't know why, but it just doesn't seem right to me as far as OOP principles go. I mean, does a database contain a select object which contains a from object which contains a where object and so on? Maybe I am thinking too much in terms of composition. I mean it's nice to have a shortcut way of doing things, but how far do you go with these shortcut methods before the code becomes inflexible, etc.? What do you think of method chaining?

[shea]

It's called a "fluent interface". Martin Fowler explains it well here:
http://www.martinfowler.com/bliki/FluentInterface.html

Personally I like it. It reads like a book.

[danh2000]

I also like this approach and use it in my own query abstraction code.. I simply return $this from the method.

In my opinion, It reads better than:

$db->select('*');
$db->from('table');
... etc.. 

I mean, does a database contain a select object which contains a from object which contains a where object and so on?

select, from, where are not objects, they are methods of the db object, so they each return $this whch is an instance of the db.

[Caldus]

Oh got it.

Still though, it looks like you're calling the where() method from a "from" object and so on. You usually don't return $this in most methods so that's how it would read to people who aren't aware of the details of this technique.

[stereofrog]

It's called a "fluent interface". Martin Fowler explains it well here:
http://www.martinfowler.com/bliki/FluentInterface.html

Personally I like it. It reads like a book.

As dynamic language users, we don't have to use patterns designed to overcome java's rigidity. I agree that method chaining looks confusing (though 'cool'), in php we can write the same in a more transparent way, e.g.

$db->select(array(
   'from' => 'mytable',
   'where' => array('id', '>', 10),
   'limit' => array(10, 20)
)); 

Well, this 'array' all the time looks quite stupid... but so is the php programming.

[Selkirk]

I was not a fan of this style, but I ran across an example where it seemed to work. My original code was:

$this->addParameter(new PostParameter('name', 'name')); 

This caused confusion because the most common case is that the optional second parameter would be the same as the first. You could solve this by passing an array:

$this->addParameter(new PostParameter(array('name'=>'name', 'modelLocation' => 'name'))); 

Well, I really didn't like this. It stinks when you don't specify the optional modelLocation parameter. I generally don't like passing configuration arrays to object constructors, so I went fluid:

$this->addParameter(new PostParameter('name'))->setModelLocation('name'); 

Better, but then I adopted fluid names:

$this->defineInput(new PostParameter('name'))->bindToModel('name'); 

Now, the most common case is that both values are the same. This can be encoded now into bindToModel, which can now have its parameter be optional. So we have:

$this->defineInput(new PostParameter('name'))->bindToModel(); 

Better?

[skinny monkey]

Nice example selkirk

[dreamscape]

I agree that method chaining looks confusing (though 'cool'), in php we can write the same in a more transparent way, e.g.

$db->select(array(
   'from' => 'mytable',
   'where' => array('id', '>', 10),
   'limit' => array(10, 20)
)); 

And that is better than a fluid interface, exactly how?

That's got to be one of the worst interfaces I have ever seen. I'd personally take a crappy and poorly thought out fluid interface over that garbage any day. ;-)

[kyberfabrikken]

Maybe I'm missing a point here, but if the second parameter is optional, what about:

$this->addParameter(new PostParameter('name')); 

As you said, it's only confusing when the second parameter is equal to the first; In cases, where you do supply the second parameter, there's no confusion:

$this->addParameter(new PostParameter('name', 'foobar')); 

[stereofrog]

Better?

In general, method chaining is a good thing, as long as one follows common naming rules: methods are actions, method names are verbs, methods return objects, which are nouns.

$users->map('trim')->sort_by_id()->format_as('html')->send_to('me@mail'); 

is good, because each function is independent and has a well-defined purpose. The whole thing looks much like unix piping and is indeed very nice and useful.

[honeymonster]

That's got to be one of the worst interfaces I have ever seen. I'd personally take a crappy and poorly thought out fluid interface over that garbage any day. ;-)

Oh my, you are going to hate Rails. It is practically littered with code like this, except Rails has the "symbol" instead of plain strings.

[Selkirk]

Maybe I'm missing a point here, but if the second parameter is optional, what about:

$this->addParameter(new PostParameter('name')); 

Because this call does not have enough information to distinguish between these two cases:

1. No binding at all.
2. Bind, but use the same name as the parameter for binding.

[Caldus]

Selkirk, nice example.

In general, method chaining is a good thing, as long as one follows common naming rules: methods are actions, method names are verbs, methods return objects, which are nouns.

Yeah, I think this is a case where the naming of methods is very crucial.

[Caldus]

I also do not like configuration arrays as input either. It always seems odd to do it that way.

[Mastodont]

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);

What about speed of execution? Every reference (->) must be evaluated ... I guess that more arguments to less objects is better solution. (experience from other language)

[Jasper Bekkers]

What about speed of execution?

It's irrelevant, PHP isn't for performance, it's for convenience. For performance, use a platform optimized C++ implementation.

[Dr Livingston]

Don't worry about performance in regards to PHP5s object model as it's not here nor there; When you actually do have a performance issue, there will be other, more highter priority areas that would need to be addressed first, before you even get near hand a script.

[ctx2002]

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);

bad , bad coding for relational DB. man , spent some time learn relational theory and sql !!!

regards

[Caldus]

Tell the CodeIgniter developers that, not me. So what's wrong with it?

[ctx2002]

$this->db->select('title')->from('mytable')->where('id', $id)->limit(10, 20);

first, this is a simple sql right? how about we do it in sql:

$sql = "select tilte from mytable where id = {$id} limit 10,20";

so , what is the point to cut an sql statement into separate parts then glue it back?

second, every method try to return an object, but why a select() return an object, it does not make sense for me.

third, try to build an sql statement with over 20 lines (most complext sql statments has over 100 even 1000 lines), then tell me how you feeling with method chaining.

the method chaining is good in some context , like chaning some small procedures to finish a big procedure , but it NOT FOR cut sql statement into small pieces then glue it back.

regards

[Caldus]

but why a select() return an object, it does not make sense for me.

That was actually what I was trying to convey in my original post.

[honeymonster]

One obvious difference is that with method chaining the builder object can automatically protect against sql injection attacks.

The variable interpolated sql string is actually prone to injection attacks.

[atu]

Hi,
Should we uses a feature by the simple fact that it exists. I'm using the array way for interfaces, it works fine. Why should i use fluent interfaces?

$model->action('module_article', 'get_node_articles', 
                array(  'result'    => & $viewVar['article'],
                        'id_node'   => int,
                        'order'     => array('title' => 'asc'),
                        'limit'     => array('numItems' => int,
                                             'numPage' => int),
                        'fields'    => array('id_article','title',
                                             'header')
                    )); 

[chestertondevelopment]

I think the CodeIgniter/SQL example is just a case of unfortunate function naming. Perhaps "select('title')" should be "getField('title')".

Personally I like this way of constructing SQL queries, it makes it more obvious exactly what is happening. It also allows easier conditional elements, e.g.

$db->getFields('title')->from('mytable')->where('id', $id);
 
if ($_GET['all'] != 'true') {
    $db->limit(10);
}
 
$result = $db->retrieve(); 

As for method chaining, I think it's good in circumstances where you are constructing something or adding to something, e.g.

$output = $xml->attach(new Element)->attach(new Element)->output(); 

Seems much clearer/concise/easier-to-read than..

$xml->attach(new Element);
$xml->attach(new Element);
$output = $xml->output(); 

Obviously these examples are very primitive.

[kyberfabrikken]

$output = $xml->attach(new Element)->attach(new Element)->output(); 

Seems much clearer/concise/easier-to-read than..

$xml->attach(new Element);
$xml->attach(new Element);
$output = $xml->output(); 

Seriously? I think example #2 is much easier to read.