Should I always prefer member variables to parameters method when it makes sense?

Question

Put value as a field makes sense only if this one represents some object's state.

I wonder if this "rule" should be avoid in certain case.

Here an example, suppose this class :

public class DbCar {

    private ResultSet rs;

    public DbMapper(ResultSet rs) {
        this.rs = rs;
    }

    public Car buildObject(){
        //.....does some mappings, then returns the builded car ....
    }
}

So we see that ResultSet is stored as a member variable and it makes sense since every DbMapper like DbCar manipulates a retrieved ResultSet from JDBC query.

We would have a caller looking like as follows:

while (rs.next()) {
   items.add(new DbCar(rs)).buildObject();
}

But imagine that the current query returned 15000 records.

To put it in a nutshell => 15000 instances of DbCar objects were created.

So my question is : Is the garbage collector efficient enough so that I shouldn't worry about this huge number of instances ?

Of course, to avoid all these instances, we can refactor the code as follows:

public class DbCar {

    public Car buildObject(ResultSet rs) {
        //.....does some mappings, then returns the builded car ....
    }
}

In this case, a single instance of DbCar (in the current thread and in the current method) would be created, and the caller looking like as follows:

DbCar dbCar = new DbCar();
while (rs.next()) {
   items.add(dbCar.buildObject(rs));
} 

So, which solution should I choose ? Trust on garbage collector with a more elegant code or coding like a more procedural coding-style with local parameter method ?

In order to make choice harder, imagine that the DbCar class divides its "build" method into elegant small methods, each one dedicated to a specific responsibility like for instance :

"buildEngine", "buildDoors" etc... In case of local parameter choice, I would have to pass ResultSet into all these methods... boring and redondant isn't it ?

Answer 1

2nd is better. 15000 objects is nothing for the garbage collector, but hanging on to the resultset object is not recommended. #2 is better for that reason

Answer 2

That does not constitute a problem for the GC but it all boils down to your application requirements.

In a previous project, I was involved in developing a very big "near real time" application that runs on a Solaris server (requires 10GB of RAM to start) the application is creating something like 150000 DTO objects every 4 seconds or so. This has no impact on the GC at first glance but after some working hours, the users started complaining about the software loosing data coming out of the hardware. We spent a long night investigating the problem and we finally found out that the GC was taking full CPU to clean up the unused objects which made the application look like it hanged for a second or so (trust me, a second of data loss costs more than 1000$)