Women in Technology

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.