Hello All,
When i should go for wrapper class over primitive types? Or On what circumstance i should choose between wrapper / Primitive types?
A:
If you want to use Collections, you must use Wrapper classes.
Primitive types, are used for arrays. Also, to represent data that has no behaviour,for example, a counter, or a boolean condition.
Since autoboxing, the "when to use primitive or wrapper" frontier has become quite fuzzy.
But remember, Wrappers are objects, so you get all the fancy Java features. For example, you can use reflexion to create Integer objects, but not int values. Wrapper classes also have methods such as valueOf.
Tom
2009-10-15 05:18:33
Other than collections, i shouldn't use wrapper classes? How about using it for ordinary declaration like Integer i = new Integer(10); Is it good to do like this?
Sri Kumar
2009-10-15 05:23:37
autoboxing allows you to do Integer i = 10;
Tom
2009-10-15 05:25:26
No, Sri. If you don't have a requirement that i be an object, don't make it one.
Matthew Flaschen
2009-10-15 05:30:35
Autoboxing will unbox the above declared i to int i=10 or Integer i = 10?
Sri Kumar
2009-10-15 05:30:42
int pi = new Integer(10); works.Integer oi = 10; works. int ni = null; doesn't work.the LHS is converted to whatever the RHS requires.
pstanton
2009-10-15 05:47:25
A:
Generally, you should use primitive types unless you need an object for some reason (e.g. to put in a collection). Even then, consider a different approach that doesn't require a object if you want to maximize numeric performance. This is advised by the documentation, and this article demonstrates how auto-boxing can cause a large performance difference.
Matthew Flaschen
2009-10-15 05:18:45
the performance hit is not so great that code legibility/reliability should take a back seat.
pstanton
2009-10-15 05:39:32
First, using primitives appropriately will not make your code illegible. Second, the performance hit is significant in some cases. It's absurd to say it never is.
Matthew Flaschen
2009-10-15 06:00:28
In many cases Integer is no more legible than int and in these cases I will always use int, or if I know a certain variable will NEVER be null, i'll use int because int is as you've pointed out slightly more efficient. However, in many cases it is easier for another programmer to understand the state of a variable when an object is used, as it can be initialised to null to signify that it is not ready. For example if you have an unsaved database record which has a unique incrementing numeric id, should this id be 0, -1 or null before it is assigned a valid id? In that case Objects are better.
pstanton
2009-10-15 08:37:08
regarding performance - in special cases, the performance hit can be significant, ie if you are creating a multitude of these Objects very rapidly or if many many many of them build up over a period of time. However, i'd expect a decent programmer to be able to identify these special cases either avoid or amend accordingly. I never said that it's NEVER significant, however generally speaking, it isn't.
pstanton
2009-10-15 08:41:43
A:
If you want to create a value type. Something like a ProductSKU or AirportCode.
When a primitive type (string in my examples) defines equality, you'll want to override equality.
Chris Missal
2009-10-15 05:20:49
there are still good reasons to wrap a value type that contains a string as the base object.
Chris Missal
2009-10-15 05:36:09
your answer just doesn't make sense. i'm not sure what you're saying. i agree with your comment though, wrapper classes are a good idea if they improve legibility.
pstanton
2009-10-15 05:41:58
Value types or value objects should be created and be immutable. For instance, it wouldn't make sense to create a "CountryCode" object like:new CountryCode("USA")then create another object the same way, where later they are different. They're just strings to start with, but they have meaning behind them. By using strings, you're able to modify them (by appending more data, etc) but they would no longer be equal.See this article for a better description of what I'm trying to explain :) I hope this makes sensehttp://c2.com/cgi/wiki?ValueObject
Chris Missal
2009-10-15 06:06:51
+1
A:
I would only use the wrapper types if you have to.
In using them you don't gain much, besides the fact that they are Objects.
And, you lose overhead in memory usage and time spent boxing/unboxing.
jjnguy
2009-10-15 05:21:35
you might not gain much, but you don't lose much either. unless you're running on a 1990's palm pilot.
pstanton
2009-10-15 05:43:20
The fact that they are Objects also give them much more context and encapsulation than as a plain primitive. So you may actually gain much depending on what those primitives are meant for and where they're being used.
aberrant80
2009-10-15 06:34:59
+2
A:
Others have mentioned that certain constructs such as Collections require objects, and that objects have more overhead than their primitive counterparts (memory & boxing).
Another consideration is:
It can be handy to initialise Objects to null, or send null parameters into a method/constructor to indicate state or function. This can't be done with primitives.
Many programmers initialise numbers to 0 (default) or -1 to signify this, but depending on the scenario, this may be incorrect or misleading.
This will also set the scene for a NullPointerException when something is being used incorrectly, which is much more programmer-friendly than some arbitrary but down the line.
pstanton
2009-10-15 05:36:30
+2
A:
Collections are the typical case for the simple Java wrapper objects. However, you might consider giving the Wrapper a more specific meaning in the code (value object).
IMHO there's almost always a benefit to use value objects when it boils down to readability and maintainance of the code. Wrapping simple data structures inside of objects when they have certain responsibilities often simplifies the code. This is something that is very important in Domain-Driven Design.
There is of course the performance issue, but I tend to ignore that until I have the possibility to measure the performance with proper data and do more directed actions towards the problematic area. It might also be easier to understand the performance issue if the code is easy to understand as well.
Mattias Holmqvist
2009-10-15 06:25:09