Java - Creating a method that will set values on a object, return the object or set using the passed param?

3579 views java
-1

I am creating a method in my Java project which simply set values of an object. Common approaches are returning the object being set and the other one is setting the object which was passed in the parameter. Can you give me advantages and disadvantages of both scenario(even its memory consumption or performance or even the minor differences or when to use them), both works but maybe there are key points that I missed. Thanks!

Return the object being set.

public Car setCarDetails(){
    Car car = new Car();
    car.setName("Tesla Model S");
    car.setBrand("Tesla");
    car.setPrice(45000);
    return car;
}

Set using the object passed in the parameter

public void setCarDetails(Car car){
    car.setName("Tesla Model S");
    car.setBrand("Tesla");
    car.setPrice(45000);
}

answered question

Why don't you just create a constructor that receives those parameters?

This is a fairly false comparison: Those methods do very different things and would be designed for different purposes. You can't really directly compare them.

Do you want the user of your method to provide a Car, or do you want to create one for them? That is literally the only question, and there is no definitive answer to it. There is no "memory consumption or performance" difference, and you would do well to forget about such micro-optimisations as soon as possible.

First case honors immutability, where in concurrent environment, you are modifying same object, new instance of object will guarantee that, previous process does not get messed up. Of course it will hurt your performance. JVM is clever enough to keep up with small lived objects. Second case honors memory, but in concurrent environment, you will want to do synchronization.

@muradm - Not really, not if Car has those setXYZ methods mutating the instance like that. Now, if the first one accepted a Car and returns a new car with modifications (not using setXYZ methods), that would be a good example of using immutable objects. But the first one isn't really related to immutability, it's just a builder function.

@T.J.Crowder, true, somehow I assumed, that he wants to modify the existing object. Otherwise there is no difference or point in treating them as different methods.

1 Answer

4

These methods really do fundamentally different things, it doesn't make a lot of sense to compare them: One creates an object, sets some properties, and returns it; the other sets properties on an existing object.

Obviously, since your first version creates a new Car, and creating an object consumes memory, in that sense the first version consumes more memory than the second. But if code calling your second version had to create the Car to pass into it, there's no sigificant memory or performance difference.

It's a bit odd to have a method called "setCarDetails" that doesn't accept a Car to set them on. The method that returns a new car would typically have a name reflecting that, like "createCar" or "buildCar" or "buildCarWithDetails". But even more typically, it would simply be a constructor (and would accept the details to set, rather than hardcoding them, though of course that varies by use case).

posted this

Have an answer?

JD

Please login first before posting an answer.