File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Better design pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Better design pattern" Watch "Better design pattern" New topic

Better design pattern

Steve Chambers

Joined: Sep 19, 2006
Posts: 28
Which way is better? Is one better than the other?


Frank Carver

Joined: Jan 07, 1999
Posts: 6920
If I understand what you are getting at, the first example passes an already-created object into a method, while the second example creates the object within the method and then returns it.

Both are perfectly valid things to do, but (naturally enough) are appropriate to different situations. I can't really tell from your simple example which would be more appropriate - after all, if that's all there is to your program it would be even simpler to just write:

Having said all that, I have a general preference for passing in precreated objects, mainly because it allows for easier reuse and testing (by supplying different implmentations of the parameter object, which might be "stub" or "mock" implementations during a unit test, for example.

I feel distinctly uneasy when I see "new" in the middle of some code, especially in a non-overridable private method. There's no way in your example of using a SpecificSomething instead of a Something.

Has that helped at all?

Read about me at ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Steve Chambers

Joined: Sep 19, 2006
Posts: 28
Thank you for the response, that did help. I am going to use the 2nd way, since it makes it easier to read and understand.
Ricky Clarkson
Ranch Hand

Joined: Jul 27, 2006
Posts: 131
Although not practical everywhere, it is often a good idea to avoid modifying passed-in objects. Or even to avoid modifying any objects.

This makes the objects easier to share. For example, String is easy to share, StringBuffer isn't, because you can't rely on a StringBuffer staying the same. For instance, you couldn't do a for loop over a StringBuffer and cache the length, because another thread might change the length and make your for loop run over the bounds (exception).

Of course, if your method made the StringBuffer and hadn't given it out yet, this wouldn't be a problem.

In the cases where immutability is hard or not practical, you should make methods that mutate have a void return type. This avoids some mistakes where people assume you've made a new object.

To your specific examples - Frank is correct, the 2nd code is harder to write tests for, assuming you need to test this code independently of the Something class. However, if Something already has test cases, and is not expensive to use (doesn't do lots of I/O, etc.), then there is no benefit from testing this code independently of Something. By adding indirection (IoC, etc.), you might actually make the code harder to understand.
I agree. Here's the link:
subject: Better design pattern
It's not a secret anymore!