Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: <>
Date: 3 Jun 2006 08:27:03 -0700
Message-ID: <>

> Now, consider a change to
> the company table.
What kind of change do you have in mind?

> If you've written the sql everywhere, you need to
> change the sql everywhere. yes, a search-and-replace will help, but what
> if there is code that you don't control?
Adding columns to the company table would not need any changes in existing SQL statements.

> If instead you have a function/method/procedure
> that does the job for you, you just update that _once_, and then you only
> need to make sure that everybody uses your updated library - and nobody
> other than you actually needs to change any code at all.
If you are deleting (or adding) columns, your will most likely also change the "business object" Company. The change is not isolated to the persistence layer.

> There are also further things I would do if I found myself writing
> similar code over and over. For instance, the 'Company' class would
> probably get a constructor that takes a result row and grabs any necessary
> data itself; the construct 'execute this query, return a list of objects
> constructed from each row' would be separated out into a method, something
> like the following, in Java-esque pseudocode:

In this case to are limited to only have select statements that selects all columns from the company table. What if you need to join other tables or only select a subset of the columns.

> public class SQLUtil {
> List instantiateObjectsFromResultSet(ResultSet rs, Class c) {
> List list = new LinkedList();
> Constructor con = c.getConstructor(new Class[] {ResultSet.class});
> while ( {
> list.add(con.newInstance(rs));
> }
> return list;
> }
> List runSqlAndInstantiateObjects(String query, Class c) {
> return instantiateObjectsFromResultSet(sql(query));
> }
> }
> public class Company {
> public Company(ResultSet rs) {
> = rs.getString("id");
> = rs.getString("name");
> // ...
> }
> public static List companiesWithNameLike(String name) {
> return runSqlAndInstantiateObjects(
> "select * from company where name like '" + name + "',
> Company.class);
> }
> }

Still more code, that my original SQL statement. (The Company class could indeed be autogenerated from the schema, but OO evangelists doesn't seem to like such solution).

> Not a lot of code, very nicely separated (and thus easy to find if
> maintenance is necesary). And indeed, the SQL code that applies to the
> companies table is close together with the Java code for the Company
> class.
Yes, you can reduce the amount of work by making a 1:1 mapping between table and class. But if so, one could argue that the application still knows about the database schema. As soon as you try to make classes that are not mapped 1:1 to tables, the amount of work will quickly increase.

> >By the way, what kind of maintenance are you
> >thinking about? If I said that I want to separate all use of the
> >mathematical operators (+, -, *, /) into a separate part of the
> >application, because it makes it easier to find when it needs
> >maintenance, probably nobody would accept it.
> Consider if you are performing a certain calculation, using a certain
> formula consisting of + - * /, and you use that formula in several
> different places in your project.
> Suddenly, you are told that the formula needs to be adjusted. Now, if
> you've used the formmula itself in various places in your code, you will
> have to search through the code and replace every instance thereof with
> the new one. If, instead, you have written a function (or method, or
> procedure, or macro) that performs the calculation using that formula, you
> only need to update that one place and make sure that everyone starts
> using the updated function/method/..., and the new formula will be used
> throughout the application.

So you think is a good idea to hide all i++ statements in methods/function, like this?
function inc(i)

    return i++;

Fredrik Bertilsson Received on Sat Jun 03 2006 - 17:27:03 CEST

Original text of this message