Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Better design pattern

 
Steve Chambers
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Which way is better? Is one better than the other?



OR:

 
Frank Carver
Sheriff
Posts: 6920
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Steve Chambers
Greenhorn
Posts: 28
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 131
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic