Women in Technology

Hear us Roar



Article:
  Lisp and Java
Subject:   User
Date:   2004-03-30 08:30:40
From:   danmil
Response to: User

Interesting. What sort of problems? I like this approach because:


a) It is often the case that the object has a lot of properties to load from a db (rather than the 3 in my artificial example). Passing in a dozen arguments to a constructor is just about impossibe to get right every time (anything over three or maybe four is asking for trouble). Passing in a single ResultSet is easy to get right, and then the programmer can verify that the right members are being set from the right db fields.


b) This approach reduces a round of copying things around, which is always an opprtunity to make a mistake (esp when pulling things from a result set, where there is very limited compile-time checking).


c) You don't have any temptation to add endless get/set bean methods to your class, just to let it get appropriately initiliazed. If those members only need to be visible at construction time, it's a big win to keep them immutable once an object exists.


Similarly, I often have constructors which build things from HttpServletRequests, via getParam()


The main loss I can see is that it ties you to a specific db schema. But, IMHO, people often spend way too much energy erecting extra layers of abstraction between the db and the app, in pursuit of an abstract notion of flexibility. If you don't actually need it, the extra code makes things harder to understand and maintain.

Full Threads Newest First

Showing messages 1 through 2 of 2.

  • User
    2004-03-31 02:06:58  alanm1 [View]

    Well, I see it as an unwanted intrusion of the ugly jdbc API into application layer. It doesn't eliminate the "JDBC boilerplate", it just splinters it up and puts it in hard to find places.

    Maybe it works when well managed, but imagine a class that has:
    - some constructors that take ResultSets and some that don't.
    - constructors that pass ResultSets around to super classes, 'init' type methods and the constructors of member variables.
    - as the kicker, potentially separate try\catch blocks in all those places to which the ResultSet is used.

    Worst case scenario? Perhaps, but I've seen it.
    Maybe I'm coming across a bit strong, because I really enjoyed the article. But passing around ResultSets in constructors is something I prefer to avoid, often in favour of a big constructor.