Method chaining for model package

[Rijk van Haaften <r....@gmail.com>]

Hi all,

Using the package org.apache.ddlutils.model a few questions came to my
mind. The classes (i.e. Database, Table, Column) follow the JavaBean
structure (setters, getters, no-argument-constructor). That's quite
ok, but it has its consequences:

1. new Column() is possible but is an inconsistent object possibly
(actually seen) causing (NullPointer)Exceptions in the library. How
about adding more constructors, like Column(String name)?
2. The following
            Column c;
            Table t = new Table();
            t.setName("Meta");
            c = new Column();
            c.setName("type");
            c.setType(TypeMap.VARCHAR);
            c.setPrimaryKey(true);
            c.setSize("2048");
            t.addColumn(c);
            c = new Column();
            c.setName("super");
            c.setType(TypeMap.VARCHAR);
            c.setSize("2048");
            t.addColumn(c);
could be made more readible:
Table t =
    new Table();
        .setName("Meta");
        .addColumn( new Column()
            c.setName("type")
            c.setType(TypeMap.VARCHAR)
            c.setSize("2048")
            c.setPrimaryKey(true)
        )
        .addColumn( new Column()
            .setName("super")
            .setType(TypeMap.VARCHAR)
            .setSize("2048")
        )
if Invocation Chaining is introduced, though I would prefer
Table t =
    new Table
        ( "Meta"
        , new Column("type", TypeMap.VARCHAR, 2048, true)
        , new Column("super", TypeMap.VARCHAR, 2048)
        )
using point 1 above with varargs: Table(String name, Column... columns)

What do you think about these?

Rijk J.C. van Haaften

Re: Method chaining for model package

[Thomas Dudziak <to...@gmail.com>]

Hi Rijk,

On Thu, Feb 21, 2008 at 5:18 AM, Rijk van Haaften
<r....@gmail.com> wrote:

>  Using the package org.apache.ddlutils.model a few questions came to my
>  mind. The classes (i.e. Database, Table, Column) follow the JavaBean
>  structure (setters, getters, no-argument-constructor). That's quite
>  ok, but it has its consequences:
>
>  1. new Column() is possible but is an inconsistent object possibly
>  (actually seen) causing (NullPointer)Exceptions in the library. How
>  about adding more constructors, like Column(String name)?

File an issue in JIRA for this. Adding constructors with all required
values seems like a good idea.

>  2. The following
>             Column c;
>             Table t = new Table();
>             t.setName("Meta");
>             c = new Column();
>             c.setName("type");
>             c.setType(TypeMap.VARCHAR);
>             c.setPrimaryKey(true);
>             c.setSize("2048");
>             t.addColumn(c);
>             c = new Column();
>             c.setName("super");
>             c.setType(TypeMap.VARCHAR);
>             c.setSize("2048");
>             t.addColumn(c);
>  could be made more readible:
>  Table t =
>     new Table();
>         .setName("Meta");
>         .addColumn( new Column()
>             c.setName("type")
>             c.setType(TypeMap.VARCHAR)
>             c.setSize("2048")
>             c.setPrimaryKey(true)
>         )
>         .addColumn( new Column()
>             .setName("super")
>             .setType(TypeMap.VARCHAR)
>             .setSize("2048")
>         )
>  if Invocation Chaining is introduced, though I would prefer
>  Table t =
>     new Table
>         ( "Meta"
>         , new Column("type", TypeMap.VARCHAR, 2048, true)
>         , new Column("super", TypeMap.VARCHAR, 2048)
>         )
>  using point 1 above with varargs: Table(String name, Column... columns)
>
>  What do you think about these?

I don't like method chaining all that much, IMHO it does not make the
code easier to understand, rather the opposite.
As for varargs, DdlUtils currently is Java 1.3 (though I'll probably
switch it to Java 1.4 to make handling of JDBC 3 easier). Also, I
don't find it that much easier to read (e.g., what does the 2048 and
the true mean in the call ? It cannot be determined from just looking
at the code.)

cheers,
Tom